2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00502.txt

Text File | 1994-06-10 | 698.4 KB | 16,463 lines

[ Last modified 23 January 89 - Ken van Wyk ]

Welcome!  This is the  semi-monthly introduction posting   to VIRUS-L,
primarily for the benefit of any newcomers  to the list.   Many of you
have probably already seen  a message (or two...)  much like this, but
it does change from time to time, so I would appreciate it if you took
a couple of minutes to glance over it.



What is VIRUS-L?

It is an electronic mail discussion forum for sharing  information and
ideas about computer  viruses.  Discussions should include   (but  not
necessarily  be limited to): current  events  (virus sightings), virus
prevention    (practical  and   theoretical),    and  virus    related
questions/answers.   The list  is moderated  and digested.  That means
that  any message coming  in gets  sent  to  me,  the  editor.  I read
through the messages and make sure  that they adhere to the guidelines
of the list (see below) and add them to the  next digest.  Weekly logs
of digests are kept by the LISTSERV (see below  for  details on how to
get them).  For  those interested in statistics,  VIRUS-L is now (Jan.
23, 1989) up to 950  direct subscribers.  Of  those, approximately  80
are local redistribution accounts with an unknown number of readers.

As stated above, the list is digested and moderated.  As such, digests
go out when a) there are enough messages for  a digest, and  b) when I
put all incoming (relevant) messages into the digest.  Obviously, this
can   decrease   the  timeliness of urgent    messages such  as  virus
warnings/alerts.  For that, we have a sister list called VALERT-L.  It
is unmoderated  and undigested  - anything  going in  to the list goes
directly  out  to  all  the  subscribers, as  well  as  to VIRUS-L for
inclusion in the  next available  digest.   VALERT-L is for  the  sole
purpose of  rapidly sending out  virus alerts.   Anyone who  does  not
adhere to this  one guideline of  VALERT-L will be immediately removed
from the list.   That is, no news   is good  news.  Subscriptions  and
deletions to  VALERT-L are  handled identically as  those  for VIRUS-L
(see instructions below).


What VIRUS-L is *NOT*?

A place to  spread hype about  computer  viruses;  we already have the
Press for that.  :-) A place to sell things, to panhandle, or to flame
other subscribers.  If anyone *REALLY* feels the need to flame someone
else for something that they may have  said, then the flame  should be
sent directly to that person and/or to the list moderator  (that would
be me, <[e-mail]>).


How do I get on the mailing list?

Well, if you are  reading this, chances are *real  good* that  you are
already on the list.  However, perhaps this  document was given to you
by a friend or colleague...  So, to get onto the VIRUS-L mailing list,
send a mail message to <[e-mail]>.  In the body of the
message, say nothing more than SUB  VIRUS-L your name.  LISTSERV  is a
program which automates mailing lists such as VIRUS-L.  As long as you
are either on BITNET, or any network accessible to BITNET via gateway,
this  should work.  Within  a short time, you will  be  placed  on the
mailing list, and you will get confirmation via e-mail.


How do I get OFF of the list?

If, in  the unlikely  event, you should  happen  to want to be removed
from  the   VIRUS-L     discussion    list,   just    send   mail   to
<[e-mail]>  saying  SIGNOFF VIRUS-L.   People, such as
students, whose accounts are going to be closed (for example, over the
summer...) - PLEASE signoff of  the list before  you leave.  Also,  be
sure to send your signoff request to the LISTSERV and  not to the list
itself.  Note that the appropriate node  name is LEHIIBM1, not LEHIGH;
we have a node called LEHIGH, but they are *NOT* one and the same.


How do I send a message to the list?

Just send electronic mail  to  <[e-mail]>  and it  will
automatically be sent to the editor for possible inclusion in the next
digest to go out.


What does VIRUS-L have to offer?

All  VIRUS-L  digests  are stored in  weekly   log  files which can be
downloaded by  any user on  (or off) the mailing  list.  Note that the
log files contain all of the digests from a particular week.  There is
also a small archive  of some of the  public anti-virus programs which
are currently available.  This  archive, too,  can be accessed  by any
user.  All  of this is  handled automatically by the  LISTSERV here at
Lehigh University (<[e-mail]>).


How do I get files (including log files) from the LISTSERV?

Well, you will first want  to know what  files are   available on  the
LISTSERV.  To do this, send mail  to <[e-mail]> saying
INDEX VIRUS-L.   Note   that filenames/extensions  are  separated by a
space, and not by a period.  Once  you  have decided which file(s) you
want,  send   mail to  <[e-mail]> saying  GET filename
filetype.  For example, GET VIRUS-L LOG8804 would get the  file called
VIRUS-L LOG8804 (which happens to be the  monthly  log of all messages
sent to VIRUS-L during   April,  1988).  Note  that, starting  June 6,
1988, the logs  are weekly.  The  new file format is  VIRUS-L LOGyymmx
where yy is  the year  (88, 89, etc.),  mm is the  month, and x is the
week (A, B, etc.).  Readers who prefer digest format lists should read
the  weekly logs  and sign   off   of   the  list  itself.  Subsequent
submissions to the list should be sent to me for forwarding.

Also available is a  LISTSERV at SCFVM which  contains more anti-virus
software.   This  LISTSERV  can  be  accessed  in  the  same manner as
outlined   above,   with  the    exceptions  that    the  address   is
<[e-mail]> and that the commands to  use are INDEX PUBLIC
and GET filename filetype PUBLIC.


What is uuencode/uudecode, and why might I need them?

Uuencode and uudecode are two programs which convert binary files into
text (ASCII) files and back  again.  This  is so binary  files can  be
easily transferred via  electronic mail.  Many  of  the files on  this
LISTSERV  are binary files  which are stored in uuencoded  format (the
file types will be  UUE).  Both uuencode  and  uudecode  are available
from the LISTSERV.  Uudecode is available in BASIC and in Turbo Pascal
here.  Uuencode is available in Turbo  Pascal.  Also, there  is a very
good binary-only uuencode/uudecode  package on the LISTSERV  which  is
stored in uuencoded format.


Why have posting guidelines?

To keep the discussions on-track with what the list is intended to be;
a vehicle for virus  discussions.   This will keep the network traffic
to a minimum and, hopefully, the quality of the content of the mail to
a maximum.



What are the guidelines?

     Try to keep messages relatively short and to the  point, but with
     all relevant information included.   This serves a  dual purpose;
     it keeps network traffic to  a necessary minimum, and it improves
     the likelihood of readers reading your entire  message.

     Personal information and  .signatures  should   be  kept to   the
     generally accepted maximum of 5   lines of text.  The editor  may
     opt  to shorten  some lengthy   signatures (without deleting  any
     relevant  information, of course).  Within   those  5 lines, feel
     free to be a bit, er, creative if you wish.

     Anyone  sending  messages   containing, for  example,   technical
     information should   *PLEASE*  try  to  confirm their  sources of
     information.  When possible, site  these sources.  Speculating is
     frowned upon -  it merely  adds confusion.  This editor does  not
     have the time to confirm all contributions  to  the list, and may
     opt to discard messages which do not appear to have valid sources
     of information.

     All messages sent  to  the list  should have appropriate  subject
     lines.  The subject lines should  include the type of computer to
     which the message  refers, when applicable.  E.g., Subject: Brain
     virus detection (PC).  Messages without appropriate subject lines
     *STAND A GOOD CHANCE OF NOT BEING INCLUDED IN A DIGEST*.

     As already  stated, there will  be no flames  on the list.   Such
     messages will be discarded.

     The same goes for any commercial plugs or panhandling.

     Submissions  should be directly   or indirectly   related  to the
     subject of computer viruses.  This one is particularly important,
     other subscribers really  do not want to  read  about things that
     are  not  relevant  -    it only  adds to  network    traffic and
     frustration for the people reading the list.

     Responses to queries should be sent  to the author of  the query,
     not to the entire list.  The author should then send a summary of
     his/her responses to the list at a later date.

     "Automatic  answering machine" programs (the ones  which reply to
     e-mail for you when you are gone) should be set to *NOT* reply to
     VIRUS-L.  Such  responses sent to  the entire list are  very rude
     and will be treated as such.

     When sending in a submission, try  to see whether or  not someone
     else  may have just said  the same  thing.   This is particularly
     important when  responding to postings   from someone else (which
     should be sent to that person *anyway*).  Redundant messages will
     be sent back to their author(s).

Thank-you for your time  and for your  adherence to these  guidelines.
Comments and suggestions, as always, are invited.  Please address them
to me, <[e-mail]> or <[e-mail]>.


Ken van WykVIRUS-L Digest   Monday,  2 Apr 1990    Volume 3 : Issue 66

Today's Topics:

Stoned virus technical report (PC)
New Macintosh virus: ZUC (Mac)
Files on PC growing by 128 bytes (PC)
New ZUC virus (Mac)
Virus cure
Response to Skulason
Death of a Virus
ZUC & SAM 2.0 (MAC)

VIRUS-L is a moderated, digested mail forum for iscussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Tue, 27 Mar 90 15:05:06 -0800
From:    [e-mail] (CCML RURES)
Subject: Stoned virus technical report (PC)

Seeing the recent articles in lists.virus about the Stoned virus, I
did some recent work on clearing this virus, and prepared an article
(unpublished as at now) as appended.  It's a bit long (750 lines), so
I am hesitant to put it into the newsgroup without advice from
someone like you.

My article describes how the virus manifests itself, how it
propogates, and gives the algorithm used.  A source listing of the
code takes up 250 lines, and it might well be of interest to someone
who wishes to learn how these wretched things work.

Feel free to put it into the newsgroups or anywhere else, simply
acknowledge the source as mine.

Mike Lawrie
Director, Computing Services, Rhodes University, Grahamstown 6140, South Africa
- --- Rhodes University condemns racism and racial segregation and
strives to maintain a strong tradition of non-discrimination with
regard to race and gender in the constitution of its student body, in
the selection and promotion of its staff and in its administration.

[Ed. Thank you for your effort, Mr. Lawrie!  Due to the length of the
report, I'm placing it for anonymous FTP on cert.sei.cmu.edu, and
forwarding a copy to David Ferbrache, the U.K. VIRUS-L coordinator.
The filename on cert.sei.cmu.edu (IP # 128.237.253.5) is:

pub/virus-l/docs/stoned.descript.lawrie

]

------------------------------

Date:    Fri, 30 Mar 90 10:30:13 -0700
From:    Brian Bechtel <[e-mail]>
Subject: New Macintosh virus: ZUC (Mac)

This was posted on Applelink this morning.  Obviously, the original
message is from Compuserve.  I know nothing more than what's posted below.

- --Brian Bechtel     [e-mail]     "My opinion, not Apple's"

Sub:    New Virus Discovered

#: 38171 S12/Hot Topic
    28-Mar-90  17:47:26
Sb: #New virus: ZUC.Virus
Fm: Jeff Shulman 76136,667
To: ALL

A new virus was discovered in Italy called the ZUC.Virus (after Don
Zucchin who brought it to the attention of Francesco Giagnorio who sent it
to me) that causes the cursor to "go crazy" within a few minutes after an
infected
application is run.

PRELIMINARY information shows it to infect applications only by adding a
1256 byte piece of code at the end of the first executed CODE resource
(much the same way the ANTI virus works).

An infected application can be detected using VirusDetective 3.1.1 (or
later) by adding the search string:

 Resource Start & Pos -1256 & Data 082A#F1655#30832 ; For finding ZUC.Virus

At this point it is my personal belief that this virus is not wide-spread
since Francesco spent around a month isolating it and no other "strange"
reports have been seen. I would appreciate hearing from anyone who
discovers this virus to see just how wide-spread it is.

More info will be forthcoming as more is known about this virus.  It has
been sent to the Mash Mac Anti-Virus task force which I, and all the other
Mac anti-viral authors, are on.

 Jeff Shulman
 VirusDetective author

#: 38356 S12/Hot Topic
    29-Mar-90  11:46:49
Sb: #38328-#New virus: ZUC.Virus
Fm: Jeff Shulman 76136,667
To: Fred Hollander 72077,3544 (X)

What ZUC.Virus will do 90 seconds after launching an infected application
is take over the cursor and move it diagonally until you reboot.  After
looking at the code it seems harmless (though it can reboot your machine
if it can't get the memory it needs) but VERY infectious.  More news to
follow.  It only infects applications.

Jeff

------------------------------

Date:    30 Mar 90 11:05:00 -0500
From:    [e-mail]
Subject: Files on PC growing by 128 bytes (PC)

Where one finds a set of files that are 128 bytes too long, I would suspect
that someone used the MSDOS BACKUP utility to copy a diskful of files,
and some or all of the files were read onto the destination machine
with COPY. Diskettes created by BACKUP have all the files under their original
names, but there's a 128 byte header added to allow RESTORE to merge
pieces of files correctly (and probably tell where the file goes in
a directory tree). The resulting files sometimes will run, sometimes not,
and often appear flaky. That EVERYTHING should be 128 bytes too long sounds
like a screwup, though...not a virus.
Glenn Everhart
[e-mail]

------------------------------

Date:    Fri, 30 Mar 90 15:24:23 -0700
From:    Ben Goren <[e-mail]>
Subject: New ZUC virus (Mac)

Does anyone know if Gatekeeper/Gatekeeper Aid will block this?  It
sounds like it will, but has anyone checked?

........................................................................
 Ben Goren                                               T T T        /
     Trumpet Performance Major                    )------+-+-+--====*0
     Arizona State University                        ( --|-| |---)
     Internet: [e-mail]        --+-+-+--
........................................................................

------------------------------

Date:    30 Mar 90 23:20:39 +0000
From:    [e-mail] (Tan Nguyen)
Subject: Virus cure

Hi everyone,

One IBM PC at my office gets infected by virus.  I used Virscan(tm)
from IBM and it detected some executable files *.EXE and *.COM are
infected by 1813 or Jerusalem virus.  Anybody knows any kind of
software which can fix the don't have to reformat hard drive.  Any
public domain or commercial software can do the job?  Any information
is highly appreciated.

Thanks,

Tan Nguyen

------------------------------

Date:    Sat, 31 Mar 90 11:39:00 -0500
From:    [e-mail]
Subject: Response to Skulason

>I estimate 20 infected programs on every Jerusalem-infected machine,
>and 10 infected disketted for every Brain-infected computer.
>
>Of course, this estimate is probably wildly incorrect, but my point is that
>Jerusalem is at least as common (probably more common) than Brain, even
>though it is much younger.  So - Dr. Tippett's formula simplifies
>the situation too much.

With all due respect to Fridrik Skulason's very valuable data, he has
not seen Dr. Tippett's model, but only a brief conclusion about it
made by me.  While I think that Dr. Tippett will find Skulason's data
and analysis as interesting and useful as I do, I think that Skulason
will find the model not so naive as my brief observation might make it
appear.

>I am willing to admit that the number of viruses may increase exponentially
>at first, but I think it would slow down later.  My experience has shown,
>that once a virus manages to infect a single computer in an organization,
>it will usually spread throughout it in a month or two, no matter how large
>the organization is.  (Well, organizations here in Iceland are not
>that large - The Bank of Iceland is one of the largest and they only have
>something like 700 PCs).

To the extent that the biological analogy holds, it is clear that viruses are
self-limiting; they either kill off members of the host population or
make them immune.  However, this is one of the places that the analogy
fails us.  There is not auto-immune response to viruses; they must be
treated.  Second, treatment may not necessarily remove the machine from
the target population.

To return to the biological analogy, it clearly demonstrates that YOU CANNOT
STOP THE SPREAD BY TREATING THE SYMPTOMS OF THE INFECTED.

>The virus may remain unnoticed for a while, but once it it detected it is
>eradicated in a single day.  Usually the virus is not wiped out 100%, which
>may cause it to reappear a month or two later - and then, finally, some
>preventive software is installed.

Contrary to the impression given here, the virus is NEVER eradicated
completely.  All infected machines in a sub-population may be purged,
but the virus persists on the media vector and in other populations.

The point is that waiting until the virus appears to immunize the
population is too late.  We are and have been doing that.  It is part
of the observed doubling time.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Sun, 01 Apr 90 01:18:48 -0600
From:    Henry Treftz <[e-mail]>
Subject: Death of a Virus

    I think when a discusion of a virus and how to deal with a virus
is talked about it is a good iead to take a look at the first disease
that man has been able to eliminate totaly.  That is the Small Pox
virus.  How small pox was eliminated is fairly simple.  Frist the
conditions that led to small pox were eliminated then individual cases
were delt with and treated so they could not spread.
  So I think a simular method should be used in dealing with a
computer virus.  I would recomend a issue of National Geographic that
talked about Small Pox.  I belive the issue is from 1978 some time
but. . . .
                    Any replies or alternate thoughts are welcome
- -----------------------------------------------------------------------------
Henry A. Treftz
Student
Northern IL Univ   |[e-mail]                       |
DeKalb IL          | 'My god it's full of stars' D. Bowman   |
- -----------------------------------------------------------------------------
\c-

------------------------------

Date:    30 Mar 90 19:07:00 -0800
From:    harvard!applelink.apple.com![e-mail]
Subject: ZUC & SAM 2.0 (MAC)

For SAM 2.0 users:

A new virus has recently been discovered (now named ZUC). If you happen to run
across the ZUC with SAM 2.0, you can expect to see the following.

1) If you are running in standard, advanced, or custom levels, SAM will alert
you to ZUC's attempt to change CODE resources within applications when ZUC is
trying to spread itself. Denying this attempt with SAM keeps the infection from
spreading.

2) If you have previously inoculated your applications with Virus Clinic 2.0,
then if ZUC has infected any files since inoculation (if, for instance, you had
SAM Intercept turned off or set to basic level), then SAM will alert you to an
inoculation discrepancy when you try to launch the infected file.

3) SAM Virus Clinic will also alert you to a checksum change to any infected
files if you have turned on checksumming in the Virus Clinic scans.

4) You can configure SAM (both Virus Clinic and Intercept) to find ZUC during
scans and application launches with the new virus definition feature. Using the
Add Virus Definition option in Virus Clinic, create a new one with these
fields:

     Virus Name:   ZUC
  Resource Type:   CODE
    Resource ID:   1
  Resource Size:   Any
  Search String:   4E56FF74A03641FA04D25290    (hexadecimal)
  String Offset:   Any

You can then add this definition to both Virus Clinic and SAM Intercept.

One other note: SAM 2.0 also repairs files infected with multiple viruses!

Paul Cozza
SAM Author

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday,  3 Apr 1990    Volume 3 : Issue 67

Today's Topics:

re: Updated signature files for IBM VIRSCAN (PC)
Confirmed virus infection (PC)
More viruses from Taiwan (PC)
Disinfectant 1.7/New ZUC Virus (Mac)
Small-pox
=VIR? (Mac)
SCAN60 Trojan Reports (PC)
Re: New ZUC virus (Mac)
Re: Death of a Virus
New viruses from South Africa (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    02 Apr 90 00:00:00 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: re: Updated signature files for IBM VIRSCAN (PC)

Version 1.1 of the program (including new & larger signature files)
was recently released.   Should be available through your IBM
Marketing Representative, and perhaps some dealers.   Not sure if
there's an 800 number this time...             DC

------------------------------

Date:    Tue, 27 Mar 90 14:37:34 -0000
From:    Bob Kilgore <[e-mail]>
Subject: Confirmed virus infection (PC)

                   FOR INFORMATION ONLY:

An outbreak of Jerusalem virus, (1813) was detected here at
Oceonics FDS on 26 Mar. 1990.  There were 26 .COM and .EXE
files infected.  The infection probably occurred on the week
of 19 Mar.  It was detected quickly because the operator was
keeping track of file size on backup listings and 2 very
large programs were infected.

The system is a CAD system and is running a popular CAD
program.  There is very little else in the system other than
DOS, the CAD system, and the obligatory Norton Utilities.
The files infected were DOS files, mouse.co, xt.exe, chkdsk,
diskcopy, etc.  There were a number of the Norton programs
contaminated, he thought he had a disk problem.  Four very
large CAD programs, 204K to 387K load modules were infected
and did not perform correctly.

The CAD system is under a maintenance contract with the
vendor and within the last two weeks as undergone some major
updates.  This involved the installation of new software
modules supplied by the vendor.  This task was begun on the
week of 12 Mar. and the software became 'flaky'.  The vendor
told us they had found a bug in the new release disk's and
sent us another set that would correct the problem.

The second set were installed the week of 19 Mar.  We have
reached the conclusion that the virus was probably attached
to the second set of disks.  We could not check all of the
new disks since four were forwarded to our Gloucester
facility to upgrade there system.  It is a bit unfortunate
that the Gloucester people rang us up during my evaluation
of the problem to inform me that they had a suspected virus.

I have no hard evidence that the disk came from the vendor,
you won't find there name here, but it seems highly likely.
I want to thank Dr. Solomon for the virus tool-kit.  It did
a superb job of identification and made life easy in the
recovery of the system.  There was never any 'real' danger
since the operator is a very firm believer in regular
backups, and the retention of the backup documentation.

BOB

Forgot to mention the original update disks came from the
U.S. of A.

------------------------------

Date:    Mon, 02 Apr 90 18:49:51 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: More viruses from Taiwan (PC)

A few days ago I reported a number of computers arriving infected from
Taiwan.  This does not seem to be limited to one manufacturer (Nothern
International).

A computer from a company named "Jafuco" arrived infected with not
one, not two, but three different viruses: "Stoned", "Brain" and
"Jerusalem".

This is the first reported occurrence of "Stoned" here in Iceland, and
both "Brain" and "Jerusalem" have been very rare here.

Is there a major virus epidemic in Taiwan or what ?

- --
Fridrik Skulason      University of Iceland  |
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: [e-mail]    Fax: [phone]  |

------------------------------

Date:    Mon, 02 Apr 90 20:24:52 -0400
From:    [e-mail]
Subject: Disinfectant 1.7/New ZUC Virus (Mac)

Disinfectant 1.7
================

April 2, 1990

Disinfectant 1.7 is a new release of our free Macintosh virus
detection and repair utility.

Version 1.7 recognizes the new ZUC virus. Thanks to Don Zucchini and
Francesco Giagnorio for discovering and reporting this new virus.

The ZUC Virus
=============

The ZUC virus was first discovered in Italy in March, 1990. It is named
after the discoverer, Don Zucchini.

ZUC only infects applications. It does not infect system files or data
files. Applications do not have to be run to become infected.

ZUC was timed to activate on March 2, 1990. Before that date it only
spread from application to application. After that date, approximately
90 seconds after an infected application is run, the cursor begins to
behave unusually whenever the mouse button is held down. The cursor
moves diagonally across the screen, changing direction and bouncing
like a billiard ball whenever it reaches any of the four sides of the
screen. The cursor stops moving when the mouse button is released.

The behavior of the ZUC virus is similar to that of a desk accessory
named Bouncy. The virus and the desk accessory are different, and
they should not be confused. The desk accessory does not spread, and
it is not a virus. ZUC does spread, and it is a virus.

ZUC has two noticeable side effects. On some Macintoshes it causes the
desktop pattern to change. It also often causes long delays and an
unusually large amount of disk activity when infected applications are
opened.

ZUC can spread over a network from individual Macintoshes to servers
and from servers to individual Macintoshes.

Except for the unusual cursor behavior, ZUC does not attempt to do any
damage.

Vaccine is not effective against ZUC. GateKeeper 1.1.1, however, is
effective against ZUC.

ZUC does not change the last modification date when it infects a file,
so you cannot use the last modification dates in the Disinfectant
report to trace the source of a ZUC infection.

Other Changes in Version 1.7
============================

Some people have used ResEdit to add a copy of the standard system WDEF
0 resource to Desktop files in an attempt to inoculate their disks
against the WDEF virus, even though we do not recommend this practice.
Version 1.6 incorrectly reported that such Desktop files were infected
by an unknown strain of WDEF. This problem has been fixed in version
1.7.

Some of the nVIR clones have offensive names. These names appeared in
plain text in various resources in Disinfectant version 1.6, and caused
concern for some people who discovered them using ResEdit or a file
editor. Version 1.7 encodes the resources so that the names do not
appear in plain text.

Version 1.6 contained an error which could cause crashes, hangs,
unexpected error messages, or other unusual behavior in some
circumstances. The error is corrected in version 1.7.

How to Get a Copy of Version 1.7
================================

Disinfectant 1.7 is available now via anonymous FTP from site
acns.nwu.edu [129.105.49.1].  It will also be available soon on
sumex-aim, rascal, comp.binaries.mac, CompuServe, Genie, Delphi, BIX,
MacNet, America Online, Calvacom, AppleLink, and other popular sources
for free and shareware software.

Macinstosh users who do not have access to bulletin boards,
networks, user groups, or online services may obtain a copy of
Disinfectant by sending a self-addressed stamped envelope and an
800K floppy disk to the author at the address below.

John Norstad
Academic Computing and Network Services
Northwestern University
2129 Sheridan Road
Evanston, IL 60208

Bitnet: jln@nuacc
Internet: [e-mail]
CompuServe: 76666,573
AppleLink: A0173

------------------------------

Date:    Mon, 02 Apr 90 13:25:00 -0400
From:    [e-mail]
Subject: Small-pox

WHM:

>To return to the biological analogy, it clearly demonstrates that YOU CANNOT
>STOP THE SPREAD BY TREATING THE SYMPTOMS OF THE INFECTED.

Then H. Treftz:

>    I think when a discusion of a virus and how to deal with a virus
>is talked about it is a good iead to take a look at the first disease
>that man has been able to eliminate totaly.  That is the Small Pox
>virus.  How small pox was eliminated is fairly simple.  Frist the
>conditions that led to small pox were eliminated the individual cases
>were delt with and treated so they could not spread.

While I am sure that neither the the author nor the editor intended it,
this appears to be a rebuttal.  The description of the elimination of
small-pox is so incomplete as to suggest that hygiene, treatment, and
quarantine alone, or in combination,  might have been effective.  This is
is certainly not true in the case of small-pox and appears to be untrue
in the case of computer viruses.

While it is true that residual cases and instances of small-pox were
tracked down, one at a time, and while it is true that quarantine was
useful, the major weapon in the elimination of Small Pox was an
effective, specific, low-risk, low-cost vaccine massively and
pervasively applied.

I encourage the use of prophylaxis.   It is extremely effective against
infection by computer viruses.  If you are interesting in protecting
your system, you may rely upon it.

However, while it can protect specific systems, it cannot be applied
consistently and broadly enough to contain the growth and spread.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    02 Apr 90 10:45:59 +0000
From:    [e-mail] (Paul Andrews)
Subject: =VIR? (Mac)

Whilst trying to sort out a corrupted desktop file recently I noticed a
resource of the type '=VIR' (or maybe it was 'not equals'VIR). Anybody know
what this is? I'm running gatekeeper and use disinfectant and neither seem
bothered by its presence...

- ------------------------------------------------------------------
| Paul Andrews             | Post: Tenset Technologies Limited,  |
| [e-mail]         |       Norfolk House,                |
| Phone: [phone]    |       301 Histon Road,              |
| Fax:   [phone]    |       Cambridge CB4 3NF, UK.        |
- ------------------------------------------------------------------

------------------------------

Date:    Sun, 01 Apr 90 11:58:12 -0700
From:    [e-mail]
Subject: SCAN60 Trojan Reports (PC)

This is a forward from John McAfee:
==========================================================================

          A number of reports of a trojan in SCANV60 have been floating
around for the past two weeks, but so far I have not talked to anyone
who has a copy of this allegedly hacked version.  SCAN60 has indeed
been released and the original ZIP file size is 44482.  However, if
your ZIP file size is different than this, it does not mean that the
file has been hacked.  Many people pass on the programs in a re-Zipped
file that has been archived using a different version of ZIP, or some
people forget to pass the registration document (or other element that
they deem unessential to the utility of the package) along with the
newly Zipped file.  The critical elements are the executable files.
These files have all been validated prior to distribution and the
validation information (and VALIDATE program) are included in the
distribution file.  If the validation information is suspect, or you
believe it may also have been tampered with, you may call HomeBase 24
hours a day to access the on-line validation data base.  This data
base cannot be tampered with so the information is secure.  The same
validation program has been shipped with each version of SCAN since
version 46, so if you have a version that you trust, then you need not
replace it when new versions of SCAN are released.  If you are still
unsure, then download the validate program directly from HomeBase -
408 988 3832.  The validation information for Version 60 should be:
SCAN.EXE program size - 43,277; Creation Date - 03-18-90; Validation
method 1 - A8F6; Validation Method 2 - 1C09.
          Remember that creation dates for the ZIP file will change each
time the ZIP file is downloaded to a system.  The EXE dates inside the
ZIP file should not change.
          If anyone does have what they believe is a bogus copy of
SCANV60 then please call us at 408 988 3832.
          Thank you.

John McAfee

------------------------------

Date:    03 Apr 90 06:25:50 +0000
From:    [e-mail] (Alvaro Hui Kau)
Subject: Re: New ZUC virus (Mac)

[e-mail] (Ben Goren):
> Does anyone know if Gatekeeper/Gatekeeper Aid will block this?  It
> sounds like it will, but has anyone checked?

How about SAM or virex????

------------------------------

Date:    Tue, 03 Apr 90 06:15:13 +0000
From:    Dave Ihnat <[e-mail]>
Subject: Re: Death of a Virus

[e-mail] (Henry Treftz) writes:
>    I think when a discusion of a virus and how to deal with a virus
>is talked about it is a good iead (sic) to take a look at the first disease
>that man has been able to eliminate totaly.  That is the Small Pox
>virus.  How small pox was eliminated is fairly simple.  Frist (sic) the
>conditions that led to small pox were eliminated then individual cases
>were delt with and treated so they could not spread.
>  So I think a simular method should be used in dealing with a
>computer virus.  I would recomend a issue of National Geographic that
>talked about Small Pox.  I belive the issue is from 1978 some time
>but. . . .

Nice idea.  The problem here is that the root cause of the virus
explosion is the underlying hardware itself; unlike with humankind,
elimination of the conditions that lead to viruses basically means
redesigning the computers that are attacked to eliminate the
simplistic hardware model that allows full access to the single user.
In many instances, this is happening in a rather interesting way; as
such DOS emulators as Simultask and VP/IX mature, we're seeing people
run DOS applications on these virtual machines.  But the elimination
of the suceptibility--while, I assure you, necessary and almost a
certainty in the long run--is a significant economic undertaking that
will probably not be deemed necessary (risk vs. cost) for some time by
most vendors or corporations.

------------------------------

Date:    Tue, 03 Apr 90 09:53:55 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: New viruses from South Africa (PC)

The following viruses have recently been reported in South Africa.

                     Pretoria (alias June 16th)

Infects .COM files only, enlarging them by 879 bytes.  When an infected file
is run, all .COM files on the current drive will be infected.  This makes
the virus rather easily detectable - the time it takes to start a program
may grow enormously, as the virus does a recursive scan on the directory tree.

On June 16th, all entries in the root directory are changed to 'ZAPPED'.

The virus is reported to be encrypted.

                     Durban (alias Saturday the 14th)

This virus infects both .COM and .EXE files, adding 669-684 bytes to their
length. It is resident, and will activate on Saturday the 14th, overwriting
the first 100 sectors on drive C:  (followed by B: and A:)

I do not have any more information available, as I have not yet received a
copy of the viruses.

- --
Fridrik Skulason      University of Iceland  |
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: [e-mail]    Fax: [phone]  |

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday,  4 Apr 1990    Volume 3 : Issue 68

Today's Topics:

scan60 (PC)
Re: Death of a Virus
New files on MIBSRV (PC)
RE: Death of a virus
Request for Anit-Viral Software (Amiga)
Anti-viral software for PC
Small Pox

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Tue, 03 Apr 00 11:03:00 -0500
From:    Bob Babcock <[e-mail]>
Subject: scan60 (PC)

I tried SCAN60 on the virus-infected version of CHKDSK which was
mailed to the VALERT list; SCAN did not detect the infection.  I have
not peersonally verified that the file contained a virus, but a
partial disassembly with a debugger showed that the file has been
modified, and past messages on this list have indicated that a virus
was found in this file.

------------------------------

Date:    03 Apr 90 00:00:00 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: Re: Death of a Virus

Dave Ihnat <[e-mail]> writes:

> elimination of the conditions that lead to viruses basically means
> redesigning the computers that are attacked to eliminate the
> simplistic hardware model that allows full access to the single user.

Unfortunately, viruses do not depend on this hardware model; viruses
can spread in any system that allows both programming and information
sharing, regardless of whether or not programs have direct access to
the hardware, whether or not the system is assumed to be single-user,
and so on.  See various papers by Fred Cohen on the subject.  As long
as (roughly) some programs sometimes have write-access to some other
programs, viruses can spread.

Dave Chess
IBM T. J. Watson Research Center

------------------------------

Date:    Tue, 03 Apr 90 12:24:20 -0500
From:    James Ford <[e-mail]>
Subject: New files on MIBSRV (PC)

The following files have been placed on MIBSRV.MIB.ENG.UA.EDU (130.160.20.80)
for anonymous FTP in the directory pub/ibm-antivirus.

SCANV61.ZIP  - McAfee's SCAN 3.1V61, scans for 85 virii.  (update)
SCANRS61.ZIP - McAfee's tsr SCAN 1.4V61                      "
NETSCN61.ZIP - McAfee's NETSCAN V61                          "
CLEANP61.ZIP - McAfee's CLEAN UP program                     "

AVS214.ZIP    -  AVSEARCH - Virus Search Program V2.14 - Scan for 75 virii.
DETECT31.ZIP  -  The Detective R3.1.  File tracking/virus detector.
                 Can be used on Novell Networks. (update)
EXPEL11.ZIP   -  EXPEL V1.1 by Toltech.  Virus control device that sample/
                 track options.
HACKTHES.ZIP  -  A thesis paper on the Computer Underground.  Text includes
                 information on hackers, pirates, phreakers, etc.
HACKER.THESES -  Same as above, but not ZIPed (generic ascii text file)

Comments:  EXPEL11's virus tracker/extracter looks interesting.  Since I
don't like to keep a live virus around, I really don't know how effective
it is.  Perhaps a virus guru can give us a better opinion of this particular
option of this program?

The SCAN series of programs were download directly from McAfee's BBS on
4/2/90 at 10:30pm.  SCANV60 will remain on MIBSRV until 4/7/90 in case
requests are pending at BITFTP@PUCC.  The files were reZIPed using the
- -ex option of PKZIP for maximun compression.

NOTE:  A user has written "Why are the versions of SCAN on MIBSRV,
Simtel20 and (add your favorite BBS) different in size when they both say they
get files from Homebase?"  They have not been ZIPed for maximun compression
(ie, PKZIP -ex -a (zipname) *.*).  With PKZIP, you can have 4 levels of
compression.  Level 1 makes a ZIP file *fast* but doesn't compress it very
much.  Level 4 takes the longest to make a ZIP file, but does max compression.
So you could actually ZIP the same files 4 times and get 4 different ZIP sizes.

If your worried about McAfee's files, just run his VALIDATE program on them.
If the two generated numbers match whats posted on his board (or in the docs),
then the files are good copies.
- ----------
The usefulness of any meeting is in inverse proportion to the attendance.
- ----------
James Ford -  [e-mail], [e-mail]
              THE University of Alabama (in Tuscaloosa)

------------------------------

Date:    Tue, 03 Apr 90 13:57:00 -0600
From:    david paul hoyt <[e-mail]>
Subject: RE: Death of a virus

>     I think when a discussion of a virus and how to deal with a virus
> is talked about it is a good idea to take a look at the first disease
> that man has been able to eliminate totally...

  It was possible to eradicate smallpox because three conditions existed.
        1) Smallpox had only one host (humans).
        2) Smallpox had only one vector (humans).
        3) Smallpox could not survive outside of a host.
  To eradicate smallpox one (only) had to be assured that no human carried the
disease. WHO has accomplished this.  Currently the only copies of the smallpox
virus is in the hands of national biological weapons researchers and perhaps
some health workers.  Assuming that no one is stupid enough to release smallpox
from the labs, smallpox will never again show up in the human population.
However, other viruses will; e.g. cow-pox and AIDS.

  The same conditions do not hold true for any computer virus.  Take WDEF
for instance.  We could 'immunize' all current Mac's with Gatekeeper's Aid.
This would eliminate all active occurrences of WDEF.  However WDEF can lay
dormant on a floppy.  So when the world thinks that is safe from WDEF and stops
inoculating (as we have with smallpox) it would only take one floppy that was
hidden in someone's desk to re-infect the community all over again.

  In all probability, there will be someone to come along and write another
virus to get around our immunization program anyway.  So taking the such
draconian measures, as WHO did in the 60's and 70's for smallpox, would be
a waste of time for computer viruses.  Besides the damage is pretty slight,
when you compare it to smallpox.

  Perhaps my real point should be this

        Computer viruses are not the same thing as biological viruses.

They both have the same word in them (virus), but then so do boardroom
and bathroom.  We may see similarities between the two, but they are
really quite different.  We shouldn't push the analogy too far.  What
would we say to the janitor who says "I clean the bathroom with this
toilet cleaner, the boardroom and bathroom are both rooms, so I'll
clean the leather seats in the boardroom with this toilet scrubber."
Just because words have the same root, doesn't make them the same
thing.

david | [e-mail] | [e-mail]

------------------------------

Date:    03 Apr 90 21:47:57 +0000
From:    [e-mail] (Nigel Tzeng)
Subject: Request for Anit-Viral Software (Amiga)

I am looking for an anti-viral program like the Macintosh Vaccine/GateKeeper
programs for the Amiga.  I am also looking for an anti-viral program that will
check my hard drive for viruses on programs that I download directly to it.

I am currently running the most recent version of VirusX but it does not seem
to scan my hard drive.  So far I am hoping that the large FTP archives are
clean and merely backing up regularly.  I know this isn't particuarly safe but
I really do not want to recopy everything to a floppy so that VirusX will look
at it.  Do I have VirusX misconfigured?  The disk checked count does not
indicate that it is checking hd0:.

Thank you for any information.  I will post a synopsis of any information I get
on comp.sys.amiga.

Nigel Tzeng


-
 ------------------------------------------------------------------------------
\c-
- -
        A| Nigel Tzeng - STX Inc. - [e-mail]
     // m|
    //  i| Standard Disclaimer Applies:  The opinions expressed are my own.
\\ //   g|
 \X/    a| "Producing a system from specifications is like walking on water...
         |  It's a helluva lot easier if it's frozen" - Seen on a wall...
-
 ------------------------------------------------------------------------------
\c-
- -

------------------------------

Date:    Tue, 03 Apr 90 14:41:00 -0600
From:    Harold Esche <[e-mail]>
Subject: Anti-viral software for PC

I am putting together a diskette of anti-viral software for
distribution to faculty, staff and students at the University of
Calgary.  Since I haven't had much experience with virus attacks I
would appreciate any feedback on the pros and cons of the many
programs for fighting viruses.  I am looking for a program or a
collection of programs that will be best suited for distribution for a
wide variety of system configurations and levels of user expertise.

- - Harold Esche <Esche@UNCAMULT>

------------------------------

Date:    Tue, 03 Apr 90 20:18:51 -0500
From:    Henry Treftz <[e-mail]>
Subject: Small Pox

Okay, Okay.....
I was wrong, perhaps Small Pox is not a good example of a virus treatment
method.  However the idea of taking a strong aproach to elimination  and
a strong aproach to treatment and prevention such as the World Health Org.
did twords Small Pox I feel is still an effective method of dealing with
a computer virus problem.
                               Henry A. Treftz
- --------------------------------------------------------------------------
Henry   |    [e-mail]     arpa                    |
Treftz  |    [e-mail]                          | Hi mom
Nrth. IL|   460 Lincoln hall                                |
Univ    |   DeKalb, IL 60115                                |
- ---------------------------------------------------------------------------
P.S I do not represent NIU as an offical party, I am just a student also
    my poor spelling is NOT a reflection on our English Dept. rather it
    is just my lack of spelling ability

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday,  4 Apr 1990    Volume 3 : Issue 69

Today's Topics:

Anti-viral archive sites, introduction
amiga anti-viral sites
apple.ii anti-viral sites
atari.st anti-viral sites
mac anti-viral sites
unix anti-viral sites
docs anti-viral sites
ibmpc anti-viral sites

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Tue, 03 Apr 90 09:49:06 -1000
From:    Jim Wright <[e-mail]>
Subject: Anti-viral archive sites, introduction

# Introduction to the Anti-viral archives...
# Listing of 03 April 1990

This posting is the introduction to the "official" anti-viral archives
of VIRUS-L/comp.virus.  With the generous cooperation of many sites
throughout the world, we are attempting to make available to all
the most recent news and programs for dealing with the virus problem.
Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh
and Unix computers, as well as sites carrying research papers and
reports of general interest.

If you have general questions regarding the archives, you can send
them to this list or to me.  I'll do my best to help.  If you have a
submission for the archives, you can send it to me or to one of the
persons in charge of the relevant sites.

If you have any corrections to the lists, please let me know.

The files contained on the participating archive sites are provided freely
on an as-is basis.

To the best of our knowledge, all files contained in the archives are either
Public Domain, Freely Redistributable, or Shareware.  If you know of one
that is not, please drop us a line and let us know.  Reports of corrupt
files are also welcome.

PLEASE NOTE
The Managers of these systems, and the Maintainers of the archives, CAN NOT
and DO NOT guarantee any of these applications for any purpose.  All possible
precautions have been taken to assure you of a safe repository of useful
tools.

A continuing side note...  This is my first archive site list sent out
from my new job.  Please note that I do have a new address, although the
kind folks at ISU will continue to forward any mail sent there for me.
It looks like business as usual.  Aloha.

Jim Wright
[e-mail]

[Ed. Congratulations on the new job, Jim, and thanks for remembering
us!  Anyone who wants to update archive site information, please note
the new email address.  BTW, it's snowing in Pittsburgh today.  I
trust that the weather is a bit better there...  :-(]

------------------------------

Date:    Tue, 03 Apr 90 09:52:06 -1000
From:    Jim Wright <[e-mail]>
Subject: amiga anti-viral sites

# Anti-viral archive sites for the Amiga
# Listing last changed 30 September 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Amiga index for the virus archives can be retrieved as
                    request: amiga
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

ms.uky.edu
          Sean Casey <[e-mail]>
          Access is through anonymous ftp.
          The Amiga anti-viral archives can be found in /pub/amiga/Antivirus.
          The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

uxe.cso.uiuc.edu
          Mark Zinzow <[e-mail]>
          Lionel Hummel <[e-mail]>
          The archives are in /amiga/virus.
          There is also a lot of stuff to be found in the Fish collection.
          The IP address is 128.174.5.54.
          Another possible source is uihub.cs.uiuc.edu at 128.174.252.27.
          Check there in /pub/amiga/virus.


------------------------------

Date:    Tue, 03 Apr 90 09:52:07 -1000
From:    Jim Wright <[e-mail]>
Subject: apple.ii anti-viral sites

# Anti-viral archive sites for the Apple II
# Listing last changed 30 September 1989

brownvm.bitnet
          Chris Chung <[e-mail]>
          Access is through LISTSERV, using SEND, TELL and MAIL commands.
          Files are stored as
                    apple2-l xx-xxxxx
          where the x's are the file number.

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Apple II index for the virus archives can be retrieved as
                    request: apple
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.


------------------------------

Date:    Tue, 03 Apr 90 09:52:08 -1000
From:    Jim Wright <[e-mail]>
Subject: atari.st anti-viral sites

# Anti-viral archive sites for the Atari ST
# Listing last changed 30 September 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Atari ST index for the virus archives can be retrieved as
                    request: atari
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>.

panarthea.ebay
          Steve Grimm <[e-mail]>
          Access to the archives is through mail server.
          For instructions on the archiver server, send
                    help
          to <[e-mail]>.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.


------------------------------

Date:    Tue, 03 Apr 90 09:52:15 -1000
From:    Jim Wright <[e-mail]>
Subject: mac anti-viral sites

# Anti-viral archive sites for the Macintosh
# Listing last changed 07 November 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Mac index for the virus archives can be retrieved as
                    request: mac
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

ifi.ethz.ch
          Danny Schwendener <[e-mail]>
          Interactive access through DECnet (SPAN/HEPnet):
                    $SET HOST 57434  or $SET HOST AEOLUS
                    Username: MAC
          Interactive access through X.25 (022847911065) or Modem 2400 bps
          ([phone]):
                    # CALL B050 <cr><cr>
                    Username: MAC
          Files may also be copied via DECnet (SPAN/HEPnet) from
                    57434::DISK8:[MAC.TOP.LIBRARY.VIRUS]

rascal.ics.utexas.edu
          Werner Uhrig <[e-mail]>
          Access is through anonymous ftp, IP number is 128.83.144.1.
          Archives can be found in the directory mac/virus-tools.
          Please retrieve the file 00.INDEX and review it offline.
          Due to the size of the archive, online browsing is discouraged.

scfvm.bitnet
          Joe McMahon <[e-mail]>
          Access is via LISTSERV.
          SCFVM offers an "automatic update" service.  Send the message
                    AFD ADD VIRUSREM PACKAGE
          and you will receive updates as the archive is updated.
          You can also subscribe to automatic file update information with
                    FUI ADD VIRUSREM PACKAGE

sumex-aim.stanford.edu
          Bill Lipa <[e-mail]>
          Access is through anonymous ftp, IP number is 36.44.0.6.
          Archives can be found in /info-mac/virus.
          Administrative queries to <[e-mail]>.
          Submissions to <[e-mail]>.
          There are a number of sites which maintain shadow archives of
          the info-mac archives at sumex:
          * MACSERV@PUCC                services the Bitnet community
          * LISTSERV@RICE               for e-mail users
          * FILESERV@IRLEARN  for folks in Europe

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

wsmr-simtel20.army.mil
          Robert Thum <[e-mail]>
          Access is through anonymous ftp, IP number 26.2.0.74.
          Archives can be found in PD3:<MACINTOSH.VIRUS>.
          Please get the file 00README.TXT and review it offline.


------------------------------

Date:    Tue, 03 Apr 90 09:52:17 -1000
From:    Jim Wright <[e-mail]>
Subject: unix anti-viral sites

# Anti-viral and security archive sites for Unix
# Listing last changed 30 September 1989

attctc
          Charles Boykin <[e-mail]>
          Accessible through UUCP.

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

sauna.hut.fi
          Jyrki Kuoppala <[e-mail]>
          Accessible through anonymous ftp, IP number 128.214.3.119.
          (Note that this IP number is likely to change.)

ucf1vm
          Lois Buwalda <[e-mail]>
          Accessible through...

wuarchive.wustl.edu
          Chris Myers <[e-mail]>
          Accessible through anonymous ftp, IP number 128.252.135.4.
          A number of directories can be found in ~ftp/usenet/comp.virus/*.


------------------------------

Date:    Tue, 03 Apr 90 09:52:12 -1000
From:    Jim Wright <[e-mail]>
Subject: docs anti-viral sites

# Anti-viral archive sites for documentation
# Listing last changed 04 March 1990

cert.sei.cmu.edu
          Kenneth R. van Wyk <[e-mail]>
          Access is available via anonymous ftp, IP number 128.237.253.5.
          This site maintains archives of all VIRUS-L digests, all
          CERT advisories, as well as a number of informational documents.
          VIRUS-L/comp.virus information is in:
                    ~ftp/pub/virus-l/archives
                    ~ftp/pub/virus-l/archives/predig
                    ~ftp/pub/virus-l/archives/1988
                    ~ftp/pub/virus-l/archives/1989
                    ~ftp/pub/virus-l/archives/1990
                    ~ftp/pub/virus-l/docs
          CERT information is in:
                    ~ftp/pub/cert_advisories
                    ~ftp/pub/cert-tools_archive

csrc.ncsl.nist.gov
          John Wack <[e-mail]>
          This site is available via anonymous ftp, IP number 129.6.48.87.
          The archives contain all security bulletins issued thus far from
          organizations such as NIST, CERT, NASA-SPAN, DDN, and LLNL-CIAC.
          Also, other related security publications (from NIST and others)
          and a partial archive of VIRUS_L's and RISK forums.

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The index for the **GENERAL** virus archives can be retrieved as
                    request: general
                    topic: index
          The index for the **MISC.** virus archives can be retrieved as
                    request: misc
                    topic: index
          **VIRUS-L** entries are stored in monthly and weekly digest form from
          May 1988 to December 1988.  These are accessed as log.8804 where
          the topic substring is comprised of the year, month and a week
          letter.  The topics are:
                    8804, 8805, 8806 - monthly digests up to June 1988
                    8806a, 8806b, 8806c, 8806d, 8807a .. 8812d - weekly digests
          The following daily digest format started on Wed 9 Nov 1988.  Digests
          are stored by volume number, e.g.
                    request: virus
                    topic: v1.2
          would retrieve issue 2 of volume 1, in addition v1.index, v2.index an
\cd
          v1.contents, v2.contents will retrieve an index of available digests
          and a extracted list of the the contents of each volume respectively.
          **COMP.RISKS** archives from v7.96 are available on line as:
                    request: comp.risks
                    topic: v7.96
          where topic is the issue number, as above v7.index, v8.index and
          v7.contents and v8.contents will retrieve indexes and contents lists.
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

lehiibm1.bitnet
          Ken van Wyk <[e-mail]> new: <[e-mail]>
          This site has archives of VIRUS-L, and many papers of
          general interest.
          Access is through ftp, IP address 128.180.2.1.
          The directories of interest are VIRUS-L and VIRUS-P.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

unma.unm.edu
          Dave Grisham <[e-mail]>
          This site has a collection of ethics documents.
          Included are legislation from several states and policies
          from many institutions.
          Access is through ftp, IP address 129.24.8.1.
          Look in the directory /ethics.


------------------------------

Date:    Tue, 03 Apr 90 09:52:13 -1000
From:    Jim Wright <[e-mail]>
Subject: ibmpc anti-viral sites

# Anti-viral archive for the IBMPC
# Listing last changed 16 December 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The IBMPC index for the virus archives can be retrieved as
                    request: ibmpc
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

f.ms.uky.edu
          Daniel Chaney <[e-mail]>
          This site can be reached through anonymous ftp.
          The IBMPC anti-viral archives can be found in /pub/msdos/AntiVirus.
          The IP address is 128.163.128.6.

mibsrv.mib.eng.ua.edu
          James Ford <[e-mail]> <[e-mail]>
          This site can be reached through anonymous ftp.
          The IBM-PC anti-virals can be found in PUB/IBM-ANTIVIRUS
          Uploads to PUB/IBM-ANTIVIRUS/00UPLOADS.  Uploads are screened.
          Requests to [e-mail] for UUENCODED files will be filled
          on a limited bases as time permits.
          The IP address is 130.160.20.80.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

uxe.cso.uiuc.edu
          Mark Zinzow <[e-mail]>
          This site can be reached through anonymous ftp.
          The IBMPC anti-viral archives are in /pc/virus.
          The IP address is 128.174.5.54.

vega.hut.fi
          Timo Kiravuo <[e-mail]>
          This site (in Finland) can be reached through anonymous ftp.
          The IBMPC anti-viral archives are in /pub/pc/virus.
          The IP address is 130.233.200.42.

wsmr-simtel20.army.mil
          Keith Peterson <[e-mail]>
          Direct access is through anonymous ftp, IP 26.2.0.74.
          The anti-viral archives are in PD1:<MSDOS.TROJAN-PRO>.
          Simtel is a TOPS-20 machine, and as such you should use
          "tenex" mode and not "binary" mode to retreive archives.
          Please get the file 00-INDEX.TXT using "ascii" mode and
          review it offline.
          NOTE:
          There are also a number of servers which provide access
          to the archives at simtel.
          WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands
          from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe
          from EARN TRICKLE servers.  Send commands to TRICKLE@<host-name>
          (for example: TRICKLE@AWIWUW11).  The following TRICKLE servers
          are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium),
          DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy),
          EB0UB011 (Spain) and TREARN (Turkey).


------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday,  5 Apr 1990    Volume 3 : Issue 70

Today's Topics:

Where can i find MDISK?? (PC)
PKZ110EU.EXE - Katz's ZIP archive package v1.10, export vers.
Re: =VIR (Mac)
Should "Viruses" be callecd "vampires"?
Thanks-Virus paper
VirusX and Hard Drives
Virus in Text Files
virus hamming?
Dates: day/month/year (Europe) v. month/day/year (USA)
Viruses which kill other viruses

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    04 Apr 90 10:14:32 +0000
From:    [e-mail] (Arent Banck)
Subject: Where can i find MDISK?? (PC)

In the documentation of scanv60, I read that I needed the program
MDISK (OR M-DISK, another problem for Havel).  Where can I find this
program? I can use FTP, and I can deuuencode it if you mail it to me.
(I have A.T. computer using MS-DOS).

------------------------------

Date:    Mon, 02 Apr 90 15:35:00 -0600
From:    Keith Petersen <[e-mail]>
Subject: PKZ110EU.EXE - Katz's ZIP archive package v1.10, export vers.

The latest export version of Phil Katz's ZIP/UNZIP has been uploaded
to SIMTEL20.

Because of the laws restricting exporting encryption technology from
the USA and Canada, and because of the International nature of the
Internet, SIMTEL20 has elected to offer the export version which does
not offer certain file encryption features.

NOTE: Type B is Binary

Directory PD1:<MSDOS.ZIP>
 Filename   Type Length   Date    Description
==============================================
PKZ110EU.EXE  B  140116  900402  Katz's ZIP archive package v1.10, export vers.

Keith
- --
Keith Petersen
Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

------------------------------

Date:    Wed, 04 Apr 90 14:15:09 -0400
From:    Joe McMahon <[e-mail]>
Subject: Re: =VIR (Mac)

The "not-equals"VIR resource which you mentioned before comes from
good old Interferon. Nothing to worry about. You do have something to
worry about, though, if that's your only tool for finding viruses!

 --- Joe M.

------------------------------

Date:    Wed, 04 Apr 90 14:51:03 -0400
From:    Peter Jones <[e-mail]>
Subject: Should "Viruses" be callecd "vampires"?

On Tue, 03 Apr 90 13:57:00, in VIRUS-L Digest   Wednesday,  4 Apr 1990
Volume 3 : Issue 68, david paul hoyt <[e-mail]> said:
>Subject: RE: Death of a virus
>
>  Perhaps my real point should be this
>
>        Computer viruses are not the same thing as biological viruses.

My feeling is that "viruses" should have been called "vampires", for
they change other programs into programs like themselves. But I
suppose it's too late to turn back now.

"Let your flippers do the walking" :-)
Peter Jones                    (514)-987-3542
Internet:Peter Jones <[e-mail]>  ?
Internet:Peter Jones <[e-mail]>  ?
UUCP: ...psuvax1!uqam.bitnet!maint

------------------------------

Date:    04 Apr 90 19:10:06 +0000
From:    [e-mail] (Richard "Crash" Willis)
Subject: Thanks-Virus paper

 I would like to thank all the people who sent me material for my
Internet Worm paper and to appologize for not replying by e-mail to
everyone, but my mail server apparently did not like some addresses.
Anyway, to everyone who requested that I forward material to them,
please respond if you still need info (sorry I've taken so long to get
back) and tell me if you just want everything sent to you, or material
on a certain topic.  Again, I appologize for the lateness of this
post, and thank everyone for their help.
                                -Richard
                                 [e-mail]

------------------------------

Date:    Wed, 04 Apr 90 15:41:00 -0400
From:    The Mad Doctor <[e-mail]>
Subject: VirusX and Hard Drives

>Date:    03 Apr 90 21:47:57 +0000
>From:    [e-mail] (Nigel Tzeng)
>Subject: Request for Anit-Viral Software (Amiga)
>
>I am looking for an anti-viral program like the Macintosh Vaccine/GateKeeper
>programs for the Amiga.  I am also looking for an anti-viral program that will
>check my hard drive for viruses on programs that I download directly to it.
>
>I am currently running the most recent version of VirusX but it does not seem
>to scan my hard drive.  So far I am hoping that the large FTP archives are
>clean and merely backing up regularly.  I know this isn't particuarly safe but
>I really do not want to recopy everything to a floppy so that VirusX will look
>at it.  Do I have VirusX misconfigured?  The disk checked count does not
>indicate that it is checking hd0:.

VirusX will not check hard drives...however, Steve Tibbet has included in the
archived file a program called "kv", which will check a file for any of the
known types of viri.  It should have been in the zooed (or lharced) file you
got VirusX with.


------------------------------

Date:    04 Apr 90 15:57:50 -0500
From:    "Dr. Ruth Mazo Karras" <[e-mail]>
Subject: Virus in Text Files

I have heard of a concern that text files (consisting of plain ASCII text)
may contain viruses.  I had thought that only executable files such as
*.com or *.exe files were subject to viruses.  Which view is right?  Is there
risk in moving a text file from a mainframe to a PC?

Chris Karras   [e-mail]  or  [e-mail]

------------------------------

Date:    Wed, 04 Apr 90 17:20:33 +0000
From:    mike <[e-mail]>
Subject: virus hamming?

     hello all,

a few issues back it was mentioned that some viruses are using hamming
techniques to guard against anti-virus programs.  could someone give
me some more info about this, such as which viruses do this, where i
could get articles about viruses that do this.

thanks in advance.
mike lunny
[e-mail]

------------------------------

Date:    Thu, 05 Apr 90 10:11:40 -0000
From:    Anthony Appleyard <[e-mail]>
Subject: Dates: day/month/year (Europe) v. month/day/year (USA)

In  Virus-L  v3  #68  in  "MIBSRV   files   updated   (PC)",   James   Ford
<[e-mail]>  wrote:  These  files  were  downloaded directly from
Homebase BBS on 3/1/90 at 11:30pm. The files they replace  (SHEZ51.ZIP  and
VSUM9002.ZIP)  will  remain  until  3/5ish/90 in case requests for them are
pending at BITFTP.".

As he wrote in USA, presumably the dates are in the order  'month/day/year'
and  mean "1 March 1990" and "5ish March 1990". But in European convention,
dates are written in the order 'day/month/year', and '3/1/90' means "3  Jan
1990".  As  Virus-L  is distributed to very many people outside USA, I feel
that it would be best if users  wrote  dates  with  the  month  in  letters
('Jan', 'Feb', etc), to avoid this ambiguity.

{A.Appleyard} (email: [e-mail]), Thu, 05 Apr 90 10:03:48 BST

------------------------------

Date:    Thu, 05 Apr 90 11:19:44 -0000
From:    Anthony Appleyard <[e-mail]>
Subject: Viruses which kill other viruses

Ref the articles listed in this extract from the Virus-L vol3 index:-
SUBJECT                                                               ISSUE
<Mac: Inoculation? (spread a special virus that kills ordinary viruses?)>
[Idea for WDEF Inoculation] spread a virus that kills other viruses      33
Not such a good idea [WDEF, WDEF, WDEF]                                  34
I <<don't>> want a virus, even for it to kill other viruses!!!           36
Attempted antivirus virus? Original nVIR deleted system file, so someone
      wrote new nVIR which killed old nVIR [Re: Mac Virus Harmlessness]  36
Best not try it [Re: Idea for WDEF Innoculation]                         38
Good idea! [Re: Idea for WDEF Innoculation]                              38
............................................................................
Has  someone  already  written  something  like  this?   Klaus   Brunnstein
<[e-mail]>  's  document AMIGAVIR.A89 is
said to  contain  the  classifications  of  24  viruses  including  these:-
    12) NORTH STAR I  Antivirus-Virus (NORTH STAR Virus Strain)      =U=
    13) NORTH STAR II Antivirus-Virus (NORTH STAR Virus Strain)      =U=
    19) System Z 3.0 Antivirus-Virus (System Z Virus Strain)         =U=
    20) System Z 4.0 Antivirus-Virus (System Z Virus Strain)         =U=
    21) System Z 5.0 Antivirus-Virus (System Z Virus Strain)         =+=
What are they? What do they do?
{A.Appleyard} (email: [e-mail]), Thu, 05 Apr 90 11:06:44 BST

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  6 Apr 1990    Volume 3 : Issue 71

Today's Topics:

HACKER.THESIS, HACKTHES.ZIP (text)
Brunnstein's lists
Re: Virus in Text Files
Validating Virus Software
ftp of disinfectant problem (Mac)
Universal Virus Detector
Re: Virus cure (PC)
The ZUC virus and SAM 2.0 (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Thu, 05 Apr 90 09:14:51 -0500
From:    James Ford <[e-mail]>
Subject: HACKER.THESIS, HACKTHES.ZIP (text)

A bad copy of these files were loaded onto MIBSRV....approximately
half the thesis was missing.  This has been corrected now.

HACKER.THESIS is 152596 bytes (instead of 62504 bytes)
HACKTHES.ZIP  is  47137 bytes (instead of 19483 bytes)

Thanks to Jim Weinhold for pointing this out.....sorry for any inconvience.
- ----------
    James Ford - [e-mail], [e-mail]
Acknowledge-To: <JFORD1@UA1VM>

------------------------------

Date:    05 Apr 90 16:35:14 +0000
From:    [e-mail] (Dave Weissman)
Subject: Brunnstein's lists

Does K. Brunnstein put out a list of MAC viruses similar to the DOS
virus list (i.e. *VIR.A89).  If so, where would I find it (preferably
by anonymous FTP).

Dave Weissman
GSFCMail/X.400 Systems
Goddard Space Flight Center
NASA

------------------------------

Date:    05 Apr 90 18:29:00 +0000
From:    [e-mail] (Leonard P Levine)
Subject: Re: Virus in Text Files

[e-mail] (Dr. Ruth Mazo Karras) writes:
> I have heard of a concern that text files (consisting of plain ASCII text)
> may contain viruses.  I had thought that only executable files such as
> *.com or *.exe files were subject to viruses.  Which view is right?  Is there
> risk in moving a text file from a mainframe to a PC?

There is NO evidence that anything other than an .exe, .com, .ovl, or
.sys file can infect.  There has been talk about .pgm files (for
dBase) and lotus spreadsheets being carriers but I have no evidence of
any known.

The following file:

XPHPD[0GG0G,0G51G31GB'(G+(G:u'0g?(G>(GE1G@arwIV_F*=US@<1|_,5wXNg-7muTu(4
1m2?352t0osr2e3K1q2s0s3e0W1_F0:sss1@2G0t1k0s3p0@3T1m3>52f3>1k0t3<2C0@3T2
K1g2?0@3T1Fm3U51g3<1q0s3:0@3T1g3r1l0ts1>0I@3T1m3i52e0O2;h0L1_Eg352s0m3S2
j0W1g3of0<1;2?0r1m0s3:1>0m@3T2e0R1FH2E1m0s3:1>0B3^0=2g3=1g3s0@3T2e0@3^1t
2e0<1>0m1m0s361>0e1l0s371g3r1:0P@3T1:0P2e1hDk0s3q0V1F2M1_3_c2o3Z1=0Y1=0c
2s0o2Ag3H0CSCS1:0=F[1:0=2s0]352k0t1]2s0U390^3<1KL2D1Dc0sf1]2L0UE^1T2HfTZ
X3mS2@F5C6G3S2Y\_X3a25BB3W2HacTV^\aZ3S2gb3S2Y\_X3mSW28eebe3S2Whe\aZ3S2Y\
_X3S2<3b2B3W2Abg3S2XabhZ[3S2`X`bel3W4

is a text file that unpacks a kermit .boo format.  This is an ASCII
string that WHEN NAMED AS A .COM FILE executes.  Gives one pause doesn't
it?

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                       e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              FAX    [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


------------------------------

Date:    Wed, 04 Apr 90 23:14:00 -0400
From:    David Ward -- Computer Support/Special Needs <[e-mail]>
Subject: Validating Virus Software

Periodically we hear concerns about the validity of SCANVxx and other
antiviral programs.  I think these concerns are valid since a
virmentor creating a virus would likely take great joy in attaching
the virus software to a product designed to fight viruses.

I do not have complete confidence in our local sources of SCANVxx -- the
distribution path of the software I use is as follows:
 - a local bulletin board downloads the SCANVxx software directly from
   homebase
 - our college microlab person downloads to his PC
 - he repacks it
 - he uploads to our VAX
 - I download it from VAX to my PC
 - I copy to disks to distribute it in my department.
There is potential for infection along the way.

It would seem logical that the most reliable source for SCANVxx is the
homebase bulletin board operated by McAfee himself.  However, it is a
long distance call and when a new version is released, the line is
quite busy.

The VALIDATE program is designed to allow us to determine whether or
not these programs are intact.  But what if someone modified SCANVxx,
revalidated the program, updated the check sums in the docs, and then
repacked the programs?  We would not be able to detect the changes
since the check sums would appear to be correct. Clearly, the
validation check sums must come from a source that is different from
the source of the program.  That is, if we get SCANVxx from a local
bulletin board, then to validate it, we must compare the validation
strings we generate to those published by McAfee on his bulletin
board.

A simple solution to this problem is that when new versions of scan
are announced on this digest, the announcement should include the
validation strings given by McAfee.  Then we can download from any
local source and compare the strings published in Virus-L to
those we generate with the validate program.

- -------------------------------------------------------------------
David Ward                          Phone:  [phone]
Special Needs Dept
Seneca College                      Netnorth/Bitnet: WARD@SENECA
Toronto
- -------------------------------------------------------------------

------------------------------

Date:    Thu, 05 Apr 90 09:31:06 -1100
From:    Michael Perrone <[e-mail]>
Subject: ftp of disinfectant problem (Mac)

I am having trouble getting disinfectant to my Mac via
ftp/kermit-white knight.  I can get the .sit file over to my IBM 4381
account, and to a unix account okay but I can't get white knight to
kermit or zmodem the file properly.  When I kermit from the ibm, White
Knight recognizes it as Macbinary but the file type and creator don't
come up as SIT!, and then it bombs id 4 (divide by 0 error!) and I
have to reboot.  WK kermit has worked for me before with macbinary to
and from the IBM with .sit files.  On my unix accounts, I can't get WK
to even recognize as Macbinary.  Yes, when I ftp I am first setting it
to binary.  Does anyone else have similar problems or a solution?

       Michael Perrone, Portland State University (Oregon) Macintosh support
       [e-mail]

------------------------------

Date:    Thu, 05 Apr 90 14:17:00 -0700
From:    [e-mail] (JAMES E. MOLINI)
Subject: Universal Virus Detector

I am working with a colleague on defining a robust virus detection
utility.  The following is an extended abstract of a paper which
discusses an approach we are investigating.  The work was undertaken as
part of a research project sponsored by the National Aeronautics &
Space Administration at the Johnson Space Center.  Please look it over
and tell us (or Virus-L) what you think.

If you have questions, or see a flaw in the process, please let us
know.  We are building a virus detector, which could be placed into the
public domain, that uses the techniques below to detect virus
infections.  Our initial tests have shown encouraging results.


                   A Universal Virus Detection Model
                      **** EXTENDED ABSTRACT ****

                     by Chris Ruhl and James Molini
                        Computer Sciences Corp.
                  Email: [e-mail]

[Ed. Thanks for the paper!  Those interested in reading the remainder
of this paper can get it by anonymous FTP from cert.sei.cmu.edu in
file:

pub/virus-l/docs/universal.detector.molini

In addition, I'm sending a copy of the paper to the U.K. comp.virus
archive site.]

This paper attempts to define an abstract model which will support the
construction of a Universal Virus Detector.

DEFINITIONS

VIRUS - A self-replicating program that must attach itself in some way
to an existing executable on the target computer system in order to
propagate.  In doing so, no overt user action is required to further
the replication process.

TROJAN HORSE - A non-replicating malicious program that misleads the
user in order to cause him/her to execute it's malicious code.
This type of program does not necessarily modify any existing
executable files on the system.

MASKING - The act of preventing discovery by intervening at some point
in the scanning process.  Typically this effects an indication of a
clean system, when, in fact, the environment under review has been
modified.

                       A Virus Propagation Model

In order to develop this model the following assumptions are made:

     a.) The user will begin the detection process (we have proposed a
         CRC type routine) prior to infection.  By doing so, the user
         has provided an uninfected baseline from which to judge future
         states.

     b.) The user will avoid the introduction of self modifying code
         into the system.  By doing so, he/she ensures that the target
         system maintains a given state of integrity.

Given the assumptions above, we may now define the circumstances
necessary to support a virus infection.  Without the adherence to the
following rules, it is impossible to define a circumstance in which a
virus can propagate.

Rule #1:    A Virus infection, or propagation occurs when an
            executable file is altered.

Rule #2:    Assuming that the detection mechanism is sufficiently
            robust, the only possible way to avoid detection is to mask
            the infection prior to having the detection results
            presented to the user.

UVD CONSTRUCTION.

>From the above discussion, we can begin defining a UVD with some degree
of assurance that it will do the job.  If a virus must modify the
original state of the system in order to be successful, we can define a
process that can detect that modification.  (Insert your favorite
Checksum/CRC/Cryptographic routine here.)  Any program which
circumvents the modification of existing code is not a virus.

Then, to defeat the detection process, the virus must mask the
infection in some way so that this verifiable change detection
mechanism cannot present accurate results to the user.

Any program which circumvents the detection mechanism must do so by
modifying the data delivery process into, or out of the detector.  Once
again we are talking about code modification.

So to put our theoretical UVD into practice, on, for example, an IBM
PC, we would do the following:

a.  Begin by validating the integrity of the detector code.  This has
    been discussed above. [not included in abstract]

b.  Validate the integrity of the read process by checking the
    interrupt table and low memory for changes.

c.  Validate the correctness of the output process by checking screen
    write interrupt vectors and device paths.  It could be done also by
    generating a direct write procedure to hardware addresses during
    the installation process.

d.  Validate the Boot sector of the disk and hidden R/O system files
    via direct sector reads.  Knowing that the read process is
    unchanged, we can also be sure that the data coming into the CRC
    routine is correct.

e.  Once both ends of the pipe and the pipe itself are validated, we
    can begin checking all executables on the system for modifications.

f.  In order to prevent a virus from attacking the CRC table, we will
    add a set of dynamic "State Vectors" for the machine, which define
    the run time environment for the detector.  This creates an
    unforgeable "fingerprint" of the detector as it exists in memory
    and can be prepended to each file prior to computing the CRC.

By doing this we have checked the entire data path and found it to be
correct.  We have also checked the correctness of the change detection
procedure.  This assumes that no other process has taken over the CPU
during the scan, but this is no problem as long as we mask all external
interrupts.  Then only an actual hardware interrupt can cause the
program to pause.

User involvement in the procedure can be coached by the detector.
[Not included in abstract.]

------------------------------

Date: 5 Apr 90 23:15:40 GMT
From: <[e-mail]>
Subject: Re: Virus cure (PC)

[e-mail] writes:
> One IBM PC at my office gets infected by virus.  I used Virscan(tm)
> from IBM and it detected some executable files *.EXE and *.COM are
> infected by 1813 or Jerusalem virus.  Anybody knows any kind of
> software which can fix the don't have to reformat hard drive.  Any
> public domain or commercial software can do the job?  Any information
> is highly appreciated.

I have run into Jerusalem virus myself.And as far as I can tell, there
is one program that I think will help you out. The program is called
m-jruslm. I tried it quite a few times and it seemed to work fine
except on a few occasion. There is another program called "clean",
which doesn't seem to disinfect the Jerusalem virus when I tried them.
I think you can find them in SIMTEL, and best of all they are
shareware.  You can try for a couple of days before purchasing them.
Hope this helps.

Roslan MdZaki.

------------------------------

Date:    Thu, 05 Apr 90 20:09:47 -0300
From:    Peter J Gergely <[e-mail]>
Subject: The ZUC virus and SAM 2.0 (Mac)

>From comp.sys.mac:

Date: 3 Apr 90 14:37:37-GMT
From: Joel B Levin <[e-mail]>
Subject: The ZUC virus and SAM 2.0
Sender: [e-mail]
Reply-To: [e-mail] (Joel B Levin)
Organization: BBN Communications Corporation

SAM Intercept can also prevent infection by the ZUC virus (at least
version 2.0 with "standard" or higher protection turned on).  The
information below was provided by the author of SAM to the Virus-L
list and comp.virus.
- - - - - -
For SAM 2.0 users:

A new virus has recently been discovered (now named ZUC). If you
happen to run across the ZUC with SAM 2.0, you can expect to see the
following.

1) If you are running in standard, advanced, or custom levels, SAM
will alert you to ZUC's attempt to change CODE resources within
applications when ZUC is trying to spread itself. Denying this attempt
with SAM keeps the infection from spreading.

2) If you have previously inoculated your applications with Virus
Clinic 2.0, then if ZUC has infected any files since inoculation (if,
for instance, you had SAM Intercept turned off or set to basic level),
then SAM will alert you to an inoculation discrepancy when you try to
launch the infected file.

3) SAM Virus Clinic will also alert you to a checksum change to any
infected files if you have turned on checksumming in the Virus Clinic
scans.

4) You can configure SAM (both Virus Clinic and Intercept) to find ZUC
during scans and application launches with the new virus definition
feature. Using the Add Virus Definition option in Virus Clinic, create
a new one with these fields:

     Virus Name:   ZUC
  Resource Type:   CODE
    Resource ID:   1
  Resource Size:   Any
  Search String:   4E56FF74A03641FA04D25290    (hexadecimal)
  String Offset:   Any

You can then add this definition to both Virus Clinic and SAM
Intercept.

One other note: SAM 2.0 also repairs files infected with multiple
viruses.

Paul Cozza
SAM Author
- - - - - - -
Nets: [e-mail]  |  "There were sweetheart roses on Yancey Wilmerding's
 or {...}!bbn!levin  |  bureau that morning.  Wide-eyed and distraught, she
POTS: [phone]  |  stood with all her faculties rooted to the floor."


------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday,  9 Apr 1990    Volume 3 : Issue 72

Today's Topics:

Viruses in Data Files
FTP from SIMTEL20 to VM/CMS (Internet)
Viruses in Data
ChessMaster 2100 & WDEF A (Mac)
Re: Virus in Text Files
Re: Virus in Text Files
Re: =VIR? (Mac)
Re: Virus in Text Files
Re: Death of a Virus
April 1 virus ??? (Unix)
New files on MIBSRV
Re: Virus in Text Files
Virus? (Mac)
AIDS Virus Suspect
Re: Validating Virus Software
Re: Universal Virus Detector

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 06 Apr 90 09:46:00 -0400
From:    [e-mail]
Subject: Viruses in Data Files

>There is NO evidence that anything other than an .exe, .com, .ovl, or
>.sys file can infect.  There has been talk about .pgm files (for
>dBase) and lotus spreadsheets being carriers but I have no evidence of
>any known.

"Not so, Mr. Schuyler!"

That is a very large NO, and I do not wish to get into a shouting match
with my learned colleague.  Neither do I wish for the rest of you to be
mislead.

First, I think that my colleague speaks in the very narrow sense of
MS-DOS.  While this is the important territory for the moment, it is not
all there is.

Ken Thompson, in his Turing Award acceptance, describes a very credible
scenario of a virus in source code.  He makes the relevant point.  "One
man's data is another man's program."

There is very credible evidence that a 1-2-3 .wks file, which looks for
all the world like a data file, can contain a macro which will create a
copy of itself in all .wks files such that use of those will cause
further copies.  That sounds like a virus to me.

It is not clear that such a .wks file could achieve the feat of
infecting .exe or .com files.  And it is clear that it can only execute
in a 1-2-3 environment.  It cannot operate in a DOS, UNIX, or primitive
hardware environment.  But that was a BIG no, we do not wish to mislead,
One man's data is another's program, and not everyone operates in a DOS
only environment.

My point is that anyone can tell a lie a in any language.  Whenever you
accept ANY data from another, you run some risk of being duped.  While
it is true that the virus writer must solve the problem of getting his
program in control, and that that problem is more easily solved in some
environments than in others, do not under-estimate the ingenuity of the
malicious.

While the current battle is being waged on the PC battlefield, and while the
war may even be won or lost here, the phenomenon should be known in the
broadest and most general light.

William Hugh Murray
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Fri, 06 Apr 90 10:19:00 -0400
From:    <[e-mail]>
Subject: FTP from SIMTEL20 to VM/CMS (Internet)

 Michael,

      It sounds like I've had the same problems you've had when trying to FTP
 Disinfectant.  I can successfully FTP Disinfectant to my VM/XA SP2 CMS
 minidisk, but when it comes time to download it to a Mac, the file is all
 garbled.  In spite of several months of trying, I have still never
 successfully obtained Disinfectant over the Internet.  I believe the problem
 has something to do with 7 databit vs. 8 databit binary.  However, I just
 FTP'd the following help file from SIMTEL20.  Although it's not Mac-specific
 and I haven't tested it yet, I think the FTP command TYPE L 8 is the missing
 link.  Hope this helps....

[Ed. SIMTEL20 is a TOPS-20 system, which is 36 (!) bit based - this
confuses many systems, but most FTP implementations can handle it.  On
UNIX systems, issue the "tenex" command at the "ftp>" prompt to set
the data type appropriately.]

 ---------------------------------------
 This file is presented for those who wish to transfer BINARY(8) files
 from SIMTEL20.ARPA to IBM/CMS hosts.

 Date: Monday, 4 July 1988  06:15-MDT
 From: Robert E. Zaret <[e-mail]>
 To:   [e-mail]
 Re:   SIMTEL20->CMS->DOS Success

 I recently requested help transferring files from SIMTEL20 to my micro via
 an IBM mainframe.  After reading several replies (thanks :-) and
 experimenting a bit, I have succeeded.  The trick is to issue the FTP
 command TYPE I followed by TYPE 8 before transferring a file (actually,
 TYPE 8, TYPE 32, and QUOTE TYPE seem to have the same effect).

 A few details: I am using MS-Kermit 2.30 and a modem to connect my micro
 to an IBM 4381 via a Series/1 protocol converter.  The 4381 is running
 CMS.  I use FTP on the 4381 to connect to SIMTEL20.  The following
 "recipe" successfully transferred the file from FTP to my micro:

 1)  start up FTP on the 4381 and connect to SIMTEL20
 2)  issue the FTP command TYPE I
 3)  issue the FTP command TYPE L 8
     (or TYPE L 32 or QUOTE TYPE L 8)
 4)  use the FTP command CWD to get to the right SIMTEL20 directory
 5)  use the FTP command GET to transfer the file to the 4381
 6)  use the FTP command QUIT to log off SIMTEL20 and shut down FTP
 7)  start up CMS-Kermit on the 4381
 8)  issue the CMS-Kermit command SET FILE-TYPE BINARY (MS-Kermit doesn't
 need to be "told" that the file type is binary, but other communications
 packages, such as ProComm, do need to be "told")
 9)  use the two Kermits to transfer the file from the 4381 to my micro
 10) "unarc" the file if it is an ARC file (I use ARCE30F).

 The FTP commands TYPE L 8, TYPE L 32, and QUOTE TYPE L 32 seemed to have
 identical effects.  The copies of the file were the same length according
 to both CMS and DOS, and ARCE30F was able to "unarc" all three.

 The FTP command TYPE L 8 was inadequate unless preceded by TYPE I The FTP
 command TYPE I was inadequate unless followed by TYPE L 8, TYPE L 32, or
 QUOTE TYPE L 8.  The version of FTP I use does not recognize the TENEX
 command.

------------------------------

Date:    Fri, 06 Apr 90 10:12:00 -0400
From:    [e-mail]
Subject: Viruses in Data

Fred Cohen uses the term "transitivity" to describe the potential of
data to flow between compartments within a system.  However, the term is
also used to describe the propensity for data to become a program.  That
is, how likely is the data to influence the behavior of the system.

Let us take for example an ATM.  I can put data in it.  The data that I
put in influences the behavior of the system in a limited way.  It would
not be fair to say that it has no influence at all.

On the other hand, it cannot cause any change to the program library of
the ATM or of the host system.  I would have great difficulty entering a
virus through such a portal.  I would have difficulty entering any data
that could cause an unintended copy of itself, executable or otherwise,
through such portal.

It is possible to think of restricting the generality of a port, or even
of a whole computer, such that its programs  cannot be modified in any
way.  An arcade game is an example;  a user can hardly enter data that
will persist longer than the privilege afforded by one twenty-five cent
token.  The program may be stored in read-only storage.  Yet, somehow I
persist in believing that the originator of that program reserved to
himself to make late modifications to the program.

Does not this reserved privilege contain the potential to enter
malicious changes?

Cohen asserts that one way to deal with the virus problem would be to
move to application-only machines.  Others who have posted to this list
insist that the virus problem is caused, not by the size of the
population of PCs, but by the generality of its architecture and the
ease with which programs can be changed.

Are there useful lines, between these two extreme, that we can draw?

William Hugh Murray
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Fri, 06 Apr 90 07:53:59 -0700
From:    Brian Bechtel <[e-mail]>
Subject: ChessMaster 2100 & WDEF A (Mac)

The following message was posted to Apple's Applelink developer services
board.  I know nothing more than what is listed below.  I did not
originate the message.

**********

ChessMaster 2100 & WDEF A

At ComputerWare, we found out that the game ChessMaster 2100 (by Software
Toolworks) is recognized by SAM, GateKeeper, and other anti-viral programs
as containing RWDEF A.S We found that GateKeeper found RWDEF AS on a number of
 UNOPENED boxes of the game that we pulled off the shelf in our warehouse.

At first, Software Toolworks denied that they were distributing a
virus-infected product, but they are looking into the matter.

Can anyone confirm or deny this? Hope to hear some feedback on this one...

- -Peter Corless.
ComputerWare Tech Support.
[phone].

*******
end posted message
*******
- --Brian Bechtel     [e-mail]     "My opinion, not Apple's"


------------------------------

Date:    06 Apr 90 16:55:36 +0000
From:    cdss![e-mail] (Tom Culliton)
Subject: Re: Virus in Text Files

[e-mail] (Dr. Ruth Mazo Karras) writes:
> I have heard of a concern that text files (consisting of plain ASCII text)
> may contain viruses.  I had thought that only executable files such as
> *.com or *.exe files were subject to viruses.  Which view is right?  Is there
> risk in moving a text file from a mainframe to a PC?

How many times has this question been answered?  If you can't execute
the file or run it via an interpreter it can't carry a virus.  If its
source code for a compiler or interpreter the danger is present that
it contains malicious instructions but visual inspection can quickly
settle that.  Most viruses are on PC class machines and are specific
to one architecture.  Moving a text file from a mainframe to a PC is
about as safe as you can get without typing with c*****ms on your
fingers.  The rest is all chicken little syndrome from people who
don't know what they're talking about.  (Sorry if that sounded a bit
hot, I've been fighting a running battle with the chicken little types
about it.)  BTW, Modem viruses and setup memory viruses are also
fictional for the same reason, its simply not possible to execute
them.

------------------------------

Date:    06 Apr 90 19:12:21 +0000
From:    [e-mail] (David J. Birnbaum)
Subject: Re: Virus in Text Files

It is possible for a text file to contain ansi instructions to remap
your keyboard, e.g., mapping a format or a global delete command (with
the appropriate response to any y/n query) to a single key.

This is not a virus, but it can be considered a trojan horse.

The ansi command will only take effect if the file is typed to the
screen; merely having it around does no harm, nor does looking at it
with other types of file viewers.

Ansi commands will only work if you are running an ansi driver of some
sort.  Keyboard remapping only works if you have configured your
ansi driver to allow it.  I use PC Magazine's ansi.com version 1.3 and
configure it to disallow keyboard remapping.

- -David

============================================================
David J. Birnbaum         [e-mail] [Internet]
                          [e-mail]   [Bitnet]
============================================================

------------------------------

Date:    04 Apr 90 03:38:26 +0000
From:    [e-mail] (Robert J Woodhead)
Subject: Re: =VIR? (Mac)

[e-mail] (Paul Andrews) writes:

>Whilst trying to sort out a corrupted desktop file recently I noticed a
>resource of the type '=VIR' (or maybe it was 'not equals'VIR). Anybody know
>what this is? I'm running gatekeeper and use disinfectant and neither seem
>bothered by its presence...

<not equal to>VIR is the application signature of Interferon.  VIRx is
the app sig of early versions of VIREX, VIRy is the app sig of the current
VIREX, and for all I know, VIRz will be the app sig of some future version
of the program.

- --
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!

------------------------------

Date:    Fri, 06 Apr 90 17:15:24 +0000
From:    [e-mail] (Peter da Silva)
Subject: Re: Virus in Text Files

There's one class of text files that can easily carry viruses: program
source files. See my "usenet virus" article (first posted shortly
before the Internet Worm incident, reposted periodically whenever
assertions that text files or source code files are safe come up) for
more on this subject... or just consider the Obfuscated C Contest.
- --
 _--_|\  `-_-' Peter da Silva. [phone]. <[e-mail]>.
/      \  'U`
\_.--._/
      v

------------------------------

Date:    07 Apr 90 01:21:30 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: Death of a Virus

[e-mail] (David.M.Chess) writes:
>Dave Ihnat <[e-mail]> writes:
>
>> elimination of the conditions that lead to viruses basically means
>> redesigning the computers that are attacked to eliminate the
>> simplistic hardware model that allows full access to the single user.
>
>Unfortunately, viruses do not depend on this hardware model; viruses
>can spread in any system that allows both programming and information
>sharing, regardless of whether or not programs have direct access to
>the hardware, whether or not the system is assumed to be single-user,
>and so on.  See various papers by Fred Cohen on the subject.  As long
>as (roughly) some programs sometimes have write-access to some other
>programs, viruses can spread.
>
>Dave Chess
>IBM T. J. Watson Research Center

 Yes dave but under environments which use say the VM8086 model on the
386 (such as VPIX) file writability and/or hardware acces is TOTALLY
under the control of unix... weak unix security weak dos security good
unix security = good dos security in this case....
     cheers
     kelly

------------------------------

Date:    06 Apr 90 15:44:17 +0000
From:    rruxg![e-mail] (J Page)
Subject: April 1 virus ??? (Unix)

Any reports of an April Fools Day virus ...

We are running Ultrix 3.1 on a VAX 8650 and since 4/1 it has been
"hanging" about once and hour.  Since it hangs there is no crash dump
to analyze....

Nothing unusual from uerf's either.

We have had the hardware folks in and they have been replacing boards left and
right, without any success.

Please excuse the crosspost.

Any help would be appreciated.

Jim Page
Bellcore

        INTERNET:       [e-mail]
        UUCP:           ihnp4!bellcore!rruxe!jpage

------------------------------

Date:    Sat, 07 Apr 90 13:54:56 -0500
From:    James Ford <[e-mail]>
Subject: New files on MIBSRV

The following files are now available for anonymous FTP from
MIBSRV.MIB.ENG.UA.EDU (130.160.20.80) in the directory pub/ibm-antivirus:

xxencode.c     C source for xxENcode
xxdecode.c     C source for xxDEcode
uxencode.pas   VM/CMS pascal source for XX/UU encoding/decoding files.

I have taken PKZ110.EXE off the server.  I was unaware of any export control
laws concerning its data encrypting.  I will try to replace it as soon as
possible.  Thanks to Keith Petersen, Grant Deason and other who wrote me on
this.
- ----------
Be kind.  Remember everyone you meet is fighting a hard battle.
- ----------
James Ford -  [e-mail], [e-mail]
              THE University of Alabama (in Tuscaloosa)

------------------------------

Date:    07 Apr 90 22:14:42 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: Virus in Text Files

 Agreed no NON executable file can be used to infect however another
technique without providing examples would be the case of a bat file
being used to feed debug along with infectious code(SMALL) being kept
beyond the EOF marker in the last allocated cluster... note all DOS
routines(I/O) read the Entire cluster(not just up to EOF...) this can
be quite a bit of spare space on present drives... more ambitious
schemes would be a triply/redundant encrypted shadow file system using
either Hamming or other ER schemes such as Reed Solomon...this could
be used to store quite sophisticated system
penetration/Interdiction/ICE-Breakers...  with out visibility to
normal virus scanners(most use the FAT and/or Directory Structures to
analyze the disk...) this vunerability does in certain cases extend to
other OS's besides **-DOS.... Something indeed to think about....still
another reason to upgrade completely to MMU managed
architectures(386/486 etc) using the VM8086 model ...
      cheers
      kelly

------------------------------

Date:    07 Apr 90 23:30:21 +0000
From:    [e-mail] (Alan Beck)
Subject: Virus? (Mac)

We've got a problem with a bunch of Mac SE, and SE 30. We have gotten
a virus into them somehow. I have no idea how this could have
happened, since they are not networked together (other than
Appletalk), and we know 99.99995 of our software is store boughten,
right off the shelves. I'm not that familiar with Mac viruses, but
here are the symptoms:

- --It just eats up space, and makes everythink larger. It sort of became
  evident when our 20 meg hd was 27 megs...

- --It may or may not copy itself onto floppy disks that are put into the
 system.

- --It seems to have been gotten rid of, and then it comes back.

- --When we find the virus on the SE (These d
- --When we find the virus on the SE (These don't have hds) we seem to get rid
of it.

- --The SE/30 (with hd) seems to always have it.

- --The plain SE gets it from when a disk was carried from the SE/30 to the reg.
  SE. So, I know where it's coming from.

- --It hasn't done anything drastic, YET!!!

Can you please tell me what this Virus is, and how to stop it??? We
try to use the SE/30 as least as possible, so it's down 75% of the
time, so I think the virus can be left alone untill we get some
antidotes here. We have tried one (a store one, can't remember the
name), that doesn't seem to help it.

I really need some suggestions...

Here comes the screwy .sig file (I have no controll over it).....

=  CAT-TALK Conferencing Network, Prototype Computer Conferencing System  =
- -  1-800-825-3069, 300/1200/2400/9600 baud, 8/N/1. New users use 'new'    -
=  as a login id.    <<Redistribution to GEnie PROHIBITED!!!>>>           =
E-MAIL Address: [e-mail]

------------------------------

Date:    Sun, 08 Apr 90 01:57:11 -0500
From:    Mark Parr <[e-mail]>
Subject: AIDS Virus Suspect

What ever became of Dr. Joseph Popp, Jr., who was arrested in
Cleveland on charges stemming from the PC Cyborg AIDS Virus/Trojan
Horse.  Has anyone heard anything?

    Mark Parr

------------------------------

Date:    Sun, 08 Apr 90 23:44:14 +0000
From:    [e-mail] (Gary Mathews)
Subject: Re: Validating Virus Software

[e-mail] (David Ward -- Computer Support/Special Needs) writes:
>Periodically we hear concerns about the validity of SCANVxx and other
>antiviral programs.  I think these concerns are valid since a
>virmentor creating a virus would likely take great joy in attaching
>the virus software to a product designed to fight viruses.
>
>I do not have complete confidence in our local sources of SCANVxx >
>A simple solution to this problem is that when new versions of scan
>are announced on this digest, the announcement should include the
>validation strings given by McAfee.  Then we can download from any
>local source and compare the strings published in Virus-L to
>those we generate with the validate program.

        Dave, I agree with you fully and I think that the Virus
Discussion List and/or John McAfee himself should post the validate
strings to the *NET*

In fact, a list of must commonly used programs should be included on
such a list, but for now the validated strings of the lastest versions
for the scan and clean programs should be publically accessible.  Many
people will hesitate from getting an updated version because it may be
a virus in disguise.  After people can be assured that the program is
valid, then they could get the new copy and register it.

                                                Gary Mathews

-
 -------------------------------------------------------------------------------
Gary Jason Mathews      | [e-mail]
Columbia University     | Death is life's way of telling you you've been fired.
- ------------------------+ CPU time flies when you have a lot of bugs

------------------------------

Date:    09 Apr 90 03:00:22 +0000
From:    [e-mail] (Woody Baker @ Eagle Signal)
Subject: Re: Universal Virus Detector

Don't forget to check for RAM shadowed BIOS and modifications to the
bios.

Cheers
Woody

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 10 Apr 1990    Volume 3 : Issue 73

Today's Topics:

Gatekeeper 1.1.1 & Scores (Mac)
Disinfectant 1.7 and GateKeeper (Mac)
Re: Universal Virus Detector
Validate program corrupted?? (PC)
Low Level Format (PC)
Re: Validating Virus Software
Re: FTP from SIMTEL20 to VM/CMS (Internet)
What do I buy? (PC)
re: Universal Virus Detector
FTP and .hqx (Mac)
Re: Virus in Text Files (Mac)
Oops- wrong thing sent
Virus info request (PC)
Archive service at Heriot-Watt
Re: Virus in Text Files

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 09 Apr 90 10:30:00 -0400
From:    Thank you matchline <[e-mail]>
Subject: Gatekeeper 1.1.1 & Scores (Mac)

The following is an excerpt of a letter sent to John Norstadt, Author of
disinfectant and may be of interest to anyone who uses gatekeeper
____________________________________________________________________
                                                           SMU,  9-APR-1990

    John, I'm sending this to you because I think it may be of interest.  I
just downloaded gatekeeper 1.1.1 off the rice archives and was in the
process of evaluating its performance against scores, nVir and WDEF.
Immediately I found a problem.  When starting up an application already
infected with scores (on a floppy) gatekeeper announced 3 times that the
virus was attempting to infect the application and its attempt was 'vetoed'
Great so far.  However, after that initial warnining I waited about 10
minutes and then checked on the process of the attempted infection.  By
that time, pyro had come on and nothing was any different BUT when I
checked the system folder the notepad file and scrapbook files had the
'dogeared page' icon.  I ran disinfectant 1.6 and guess what the system was
infected as well as the desktop, clipboard and scrapbook.
    It seems that gatekeeper only partly protects from scores attacks.  And
worse yet disinfectant had to be run twice to completely remove all bits
and pieces of scores.

                                   - Zav

------------------------------

Date:    Mon, 09 Apr 90 12:24:33 -0400
From:    [e-mail]
Subject: Disinfectant 1.7 and GateKeeper (Mac)

Disinfectant 1.7 requires GateKeeper privileges even when just scanning.
Earlier versions only required privileges when repairing.  I wasn't aware of
this until after I had released 1.7, or I would have mentioned it in the
document.

The solution to this problem is to simply grant Disinfectant all six
GateKeeper privileges.

John Norstad
Academic Computing and Network Services
Northwestern University

------------------------------

Date:    09 Apr 90 13:45:20 +0000
From:    [e-mail]
Subject: Re: Universal Virus Detector

[e-mail] (JAMES E. MOLINI) writes:
> I am working with a colleague on defining a robust virus detection
> utility.  The following is an extended abstract of a paper which
> discusses an approach we are investigating.  The work was undertaken as
> part of a research project sponsored by the National Aeronautics &
> Space Administration at the Johnson Space Center.  Please look it over
> and tell us (or Virus-L) what you think.

This is I think the fourth serious attempt on this newsgroup to propose a
universal virus detector. Unfortunately like all the rest it won't work.

        (theoretical UVD discussion)

> So to put our theoretical UVD into practice, on, for example, an IBM
> PC, we would do the following:
>
> a.  Begin by validating the integrity of the detector code.  This has
>     been discussed above. [not included in abstract]

How? I haven't copied your entire posting in this followup because it was too
long but I couldn't see any proposed method for validating the detector code.
And an obvious way to defeat your mechanism is to overwrite the detector
program with code that always says "OK".

        ...

> f.  In order to prevent a virus from attacking the CRC table, we will
>     add a set of dynamic "State Vectors" for the machine, which define
>     the run time environment for the detector.  This creates an
>     unforgeable "fingerprint" of the detector as it exists in memory
>     and can be prepended to each file prior to computing the CRC.

What do you mean? Another obvious way to defeat the detector is to recalculate
CRCs for infected programs and put the new CRC value into the table. I don't
see any way to prevent this other than storing the table offline (which would
create what most users would consider unacceptable hassle).

Also your detector would detect most resident programs as well as multiuser
systems and upgraded versions of the operating system as viruses because it
checks the system call vectors.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
[e-mail]


------------------------------

Date:    Mon, 09 Apr 90 15:13:00 -1100
From:    <[e-mail]>
Subject: Validate program corrupted?? (PC)

I just received this message. It was posted on the RED-UG list as you can
see. If you have any questions about the message please send them to the
author of the original message.

Nino

*******************************************************************************
*JANET:       [e-mail]             | Nino Margetic         *
*EARN/BITNET: n.margetic%euclid.ucl.ac.uk@UKACRL      | University College    *
*INTERNET: [e-mail]| Dept. of Med. Physics *
*UUCP:        [e-mail]    | 11-20 Capper Street   *
*Phone:       [+44 - 1 | 01 ] 380-9846                | London WC1E 6AJ       *
*FAX:         [+44 - 1 | 01 ] 380-9577                | Great Britain         *
*******************************************************************************


- --------------- Original message follows -------------------------------
Via:     UK.AC.RUTHERFORD.MAIL ;  Mon, 9 Apr 90 14:51 GMT
         (V41 at UK.AC.UCL.EUCLID)
Received:from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 7403; Mon, 09
         Apr 90 14:50:10 BS
Received:by UKACRL (Mailer X1.25) id 7680; Mon, 09 Apr 90 14:49:57 BST
Date:    Mon, 9 Apr 90 15:17
Reply-To:Gunnar Radons <[e-mail]1>
Sender:  Red File Server Users Group <[e-mail]0FUB11>
From:    Gunnar Radons <[e-mail]1>
Subject: virus alert
To:      BSMTP <[e-mail]>

Hello netlanders,

Another topic on viruses. The german computer-journal "DOS-Shareware"
reported the following in it's No. 3 issue :

There is an infected version of SCANV58.zip. Actually the VALIIDATE
program seems to be changed. The original VALIDATE should be a .COM
file, while the corrupt is a .EXE with  46167 bytes (instead of 6485)
The original SCAN.EXE should have the values: Size: 42977 bytes,
Date: 2-15-1990, File Authentication:  Check Method 1: 2F16, Method 2:
1C57.
This message is to be found on page 77 of the above journal.

Also there are to files  "NORTSTOP.ZIP" and "NORTSHOT.ZIP" which
claim to be written by peter norton. Both contain a trojan which
erases some files between christmas and new year. To identify those
look in the .ZIP file for NORTSHOT.EXE and in the .EXE for the string
"Norton Public". If you find those trojan please inform Tony McNamara
from Norton computing (phone: US: 213/319-2076). The length of NORTSHOT
is 38907 bytes and it's date is 02.01.89 (European format I suppose).
This message is from page s6 of the above journal.

This message will be sent to RED-UG and games-l (Apr. 8. 1990).

Bye,
Gunnar

:----------------------------------------------------------------------:
:                                          ::                          :
: Gunnar Radons                            :: Gunnar Radons            :
: Astronomisches Recheninstitut Heidelberg :: s46@dhdurz1              :
: Moenchhofstr. 12-14                      ::                          :
: D-6900 Heidelberg                        :: ([phone]        :
:                                          ::                          :
:------------------------------------------::--------------------------:
:           Do you have the solution or are you the problem?           :
:----------------------------------------------------------------------:


------------------------------

Date:    Mon, 09 Apr 90 15:59:02 -0000
From:    [e-mail]
Subject: Low Level Format (PC)

Many thanks to all those who sent me messages about low-level formatting. I now
have a very clear idea of what it does and when to use it.
Great help (as usual) from the -LIST
Rgds,
Iain Noble
Teesside Polytechnic Library (UK)
- -----------------------------------------------------------------------------
Iain Noble                                   |
[e-mail]                           |  Post:  Main Site Library,
JANET: [e-mail]                    |         Teesside Polytechnic,
EARN/BITNET: LBA002%pa.tp.ac.uk@UKACRL       |         Middlesbrough,
INTERNET: [e-mail] |         Cleveland, UK, TS1 3BA
UUCP: [e-mail]            |  Phone: [phone] x 4371
- -----------------------------------------------------------------------------

------------------------------

Date:    Mon, 09 Apr 90 09:52:07 -1000
From:    Jim Wright <[e-mail]>
Subject: Re: Validating Virus Software

I am willing to start a new mothly posting, which includes validation
information for various popular anti-viral software packages.  It need
not be limited to ibmpc software.  Each author is free to choose their
own favorite validation method.  Due to the nature of this, I will
only accept information from the author, or from an authorized
individual.  (Authorized by sending me a post card.)

I will not be able to keep up with this on my own.  Out here, ftp and
modems are a bit expensive.  So I will rely on the authors to keep
this up to date.

Anyone interested, just drop me a line.

Jim

------------------------------

Date:    09 Apr 90 19:20:10 +0000
From:    [e-mail] (Werner Uhrig)
Subject: Re: FTP from SIMTEL20 to VM/CMS (Internet)

> In spite of several months of trying, I have still never successfully
> obtained Disinfectant over the Internet.  I believe the problem
> has something to do with 7 databit vs. 8 databit binary

          as was already exlained by the moderator, there is indeed a differenc
\ce
          when trying to retrieve a binary file from SIMTEL20.

          given that folks tend to have other (local) problems downloading
          binaries also, I make both binaries *AND* hexed (7-bit ASCII) version
\cs
          of all the latest Macintosh anti-virals available for ANON-FTP on
          RASCAL.ICS.UTEXAS.EDU in directory  "mac/virus-tools"

------------------------------

Date:    Mon, 09 Apr 90 16:14:49 -0600
From:    David Perales <[e-mail]>
Subject: What do I buy? (PC)

We are in the market for a good solid product for dealing with the
virus situation in the IBM world.  Hopefully something that will give
us a good basis for cures, detection and possibly prevention - a good
all-in-one package.  Any suggestions?

                                          Thanx,
                                           David

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
David Perales, M.B.A., C.S.P.               BitNet:    DPERALES@TRINITY
Micro Programmer Analyst                    telephony :[phone]
Trinity University Computing Center
715 Stadium Drive, Box 50
San Antonio, Texas 78212

------------------------------

Date:    09 Apr 90 00:00:00 -0500
From:    "David.M..Chess" <[e-mail]>
Subject: re: Universal Virus Detector

[e-mail] (JAMES E. MOLINI) writes:
> If you have questions, or see a flaw in the process, please let us
> know.  We are building a virus detector, which could be placed into the
> public domain, that uses the techniques below to detect virus
> infections.  Our initial tests have shown encouraging results. ...

These comments are based on the abstract only, not the paper
(I'll eventually figure out how to FTP from here...).

Modification detectors seem like a promising way of detecting at
least some "new" (not seen before) viruses.   The usual problems
faced by a modification detector include:

 1) A virus that knows about the detector (or about a class
    of them to which it belongs) might make changes that the
    detector won't detect.
 2) A similarly detector-aware virus might update the detector's
    database to reflect the changes it makes when it infects.
 3) A virus might (by luck or design) modify files in such a way
    that the user, presented with a list of files that have
    changed, will not notice anything wrong.
 4) If the virus is active in the system when the detector runs,
    it could lie to the detector about the state of the system.

A simple CRC approach runs into point (1): if lots of people start
using your detector, and it always uses the same CRC polynomial,
it's not all that hard for the virus to include code that patches
infected objects so that the CRC is the same as it was before
infection; a CRC isn't hard to invert.   My favorite solution to
this is to allow the user to specify his own polynomial (through
the use of a "key phrase" or whatever); other solutions also
exist (crypto-based MDC's and such).  I gather from the abstract
that the exact scheme used isn't fixed by the proposal; that's
a reasonable approach.

I gather that your point (f)
> f.  In order to prevent a virus from attacking the CRC table, we will
>     add a set of dynamic "State Vectors" for the machine, which define
>     the run time environment for the detector.  This creates an
>     unforgeable "fingerprint" of the detector as it exists in memory
>     and can be prepended to each file prior to computing the CRC.

is supposed to deal with my point (2), but I don't really
understand it.  If it's possible for the detector to update the
database (and it must be, when the user gets new pieces of
software and so on), then it's possible for a virus to as well,
if the database is ever r/w to the system while the virus is
active.

(3) is one of the harder problems, I think; in some of the
environments that are most important to protect (program
development environments, for instance), many executables
will be expected to change.   Helping the user figure out
which changes are OK and which are not is something that
needs considerable thinking about, I think.  Doing it
perfectly is probably impossible (a good reason to avoid
calling anything a "universal" virus detector...).

Most of the abstract seems to be devoted to (4); making sure
the virus isn't lurking anywhere when the detector runs.
This is the general computer-security problem of getting the
system into a trusted state; I tend to think that the
problem needs to be solved at the system level rather than
the application level (that is, there should be a good
wired-in procedure for getting the system into a trusted state,
rather than making every security application program do
it itself).   I doubt that any piece of software in DOS can
really determine that the system is trustworthy; checking
interrupt vectors doesn't tell you anything about the code
they're pointing to, for instance.  Painful as it is, the
only method I know of that I trust is booting cold from a
trusted floppydisk.

Sounds like an interesting project, though, and I -will- try
to get the full paper...

DC

------------------------------

Date:    Mon, 09 Apr 90 18:09:12 -0400
From:    Joe McMahon <[e-mail]>
Subject: FTP and .hqx (Mac)

Since I run through vast amounts of sw on various servers about the net,
and it always seems to work for me, try this:

1) ftp to whereever.
2) GET the file. No binary, no translate, zilch.
3) Transfer it up with Kermit.

My feeling is that you may be trashing the file by insisting on
transferring it as binary when it isn't. HQX format (as is used on the
FTP servers I know of) is ASCII only, designed not to get trashed by
character translations (e.g., EBCDIC to ASCII). Try not doing anything
but the transfer, and I think you'll find this will work.

 --- Joe M.

------------------------------

Date:    10 Apr 90 00:19:57 +0000
From:    [e-mail] (Woody Baker @ Eagle Signal)
Subject: Re: Virus in Text Files (Mac)

Macintosh datafiles, as I understand them, have 2 parts, a resource
fork and a data fork.  Anything in resource fork (so I've been told)
can execute.  Does this imply that one could bury a virus in the
resource fork of a data file?

I'm sure that this has been hashed over before.
Cheers
Woody

------------------------------

Date:    10 Apr 90 01:35:25 +0000
From:    [e-mail] (Richard "Crash" Willis)
Subject: Oops- wrong thing sent

OOPS! Sorry guys, I sent the wrong file to a few people. Please ask
again and I'll send the right information.  BTW- the paper itself is not
yet avalible (although that wil change in a few days) however, the
infomation I do have avalable consist of a description of Internet,
Virus De-infection, a theory on a new type of virus prevention and
several other papers.  Sorry again for the mess up.
>* Sigh *< I'd better dig out my flame-proof underware for a few days

- -Richard [e-mail]
"No matter how subtle the wizard, a dagger between the shoulderblades
seriously cramps his style"
 -Stephen Burst

------------------------------

Date:    10 Apr 90 01:58:32 +0000
From:    [e-mail] (Max Avarez)
Subject: Virus info request (PC)

Does anyone know of a virus that changes the size of PC files
(usually .exe files) to 2048K?

Also, what is the best virus detection  program for the PC?

Thanks,

Max Alvarez ([e-mail])
University of Rochester

------------------------------

Date:    Tue, 10 Apr 90 10:29:19 -0000
From:    David.J.Ferbrache <[e-mail]>
Subject: Archive service at Heriot-Watt

Just a quick note to apologise for disruption to the archive service at
Heriot-Watt over the last month. The network core is due to change to a
Sun system from an ageing Vax, in the meantime a re-organisation of archive
service will take place.

Normal service for immediate processing of email will be restored by end May.
The archive contents will be extended to include the following:

1. General document archives (viruses)
2. PC, Mac, Amiga, Atari and Apple 2 anti-viral software
3. Archives of CERT, DDN SC and other advisories
4. Patches for BSD Unix releases
5. Risks digest backissues
6. Virus-l digest backissues

In addition I am considering a protocol for access to more sensitive materials
including backissues of the Zardoz security digest, Phage mailing list
(historical material from the Internet worm period), and other lists.

These will probably be available by restricted NIFTP.

Again apologies for the disruption.

- -----------------------------------------------------------------------------
\c-
Dave Ferbrache                            Internet   <[e-mail]>
Dept of computer science                  Janet      <[e-mail]>
Heriot-Watt University                    UUCP       ..!mcvax!hwcs!davidf
79 Grassmarket                            Telephone  [phone] ext 553
Edinburgh, United Kingdom                 Facsimile  [phone]
EH1 2HJ                                   BIX/CIX    dferbrache
- -----------------------------------------------------------------------------
\c-

------------------------------

Date:    Tue, 10 Apr 90 09:27:29 -0400
From:    [e-mail] (Alan J Rosenthal)
Subject: Re: Virus in Text Files

cdss![e-mail] (Tom Culliton) writes:
>How many times has this question been answered?  If you can't execute the file
>or run it via an interpreter it can't carry a virus.

A counterexample to this assertion is the wdef viruses on the macs.  They are
carried in the Desktop file which is a data file describing the layout of the
windows.

>If it's source code for a compiler or interpreter the danger is present that
>it contains malicious instructions but visual inspection can quickly settle
>that.

You're saying that you can quickly read the source code to an entire compiler
and understand everything it does?  I find this extremely hard to believe.

ajr

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 11 Apr 1990    Volume 3 : Issue 74

Today's Topics:

Signature Programs
Re: Death of a Virus
Re: Death of a Virus
Re: Universal Virus Detector
FTPing Disinfectant
Re: Death of a Virus
validation
False Indications from VIREX 2.5.1 (MAC)
Virus on Apollo? (UNIX)
Re: Validating Virus Software

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    10 Apr 90 09:36:58 -0400
From:    Bob Bosen <[e-mail]>
Subject: Signature Programs

Several weeks ago, Ross Greenburg challenged me to obtain and post
descriptions of tests and user experiences involving use of
sophisticated authentication algorithms in the "real world" against
real viruses. Because I represent a commercial software vendor I
was hesitant to publish my own test results out of fear I would sound
biased. Most of my clients are rather secretive, and it took a while
before I was able to arrange for the following to be written and
cleared for posting. The following is a message forwarded from
Padgett Peterson, a well-known (in some circles) virus researcher,
employed by a well-known Defense Contractor. He speaks only for
himself.

Padgett conducted a detailed evaluation of a great many viral defense
products, subjecting them to a collection of viruses and stressing
them in other ways. I am posting his words for him because at the
moment, his internet access is rather awkward. He comments on valuable
ways to use authentication algorithms at all ends of the spectrum, and
I find his views similar to my own, inasmuch as my product offers
authentication algorithms at all ends of the spectrum and allows
users to "fine-tune" the sophistication of the algorithm to suit all
the extremes and norms Padgett discusses. But there are things in his
views that'll make a lot of folks happy. The following are his words:


FOR POSTING

                                                 A. Padgett Peterson


Recently, following a hiatus from the VIRUS-L forum, I have had the
opportunity to examine the continuing authentication (thank you
WordStar) saga.  All of the people involved appear to be knowledgeable
and concerned participants, yet they seem to be arguing the same side
of two different questions:

1)  Authentication of known software in a controlled unique environment

(Radai and Greenberg).

2.  Authentication of unknown, publicly transmitted software (Bosen and

Murray).

The virus issue, while a valid concern, is just a complicating factor,
since, if the software were trusted, by definition it could not be
infected.  The focus of the issue is what level of authentication is
necessary for trust.  All of the participants agree that some is
necessary - the question is how much?

My personal feeling is that an authentication algorithm may be very
simple (CRC or less) provided that it is unknown (or unpredictable).
Since my 4.77 Mhz/ST-412 museum piece is capable of a simple byte
count/XOR/ROR disk file check at 50k bytes/second (and could be faster
if done in RAM by a TSR between LORD and EXECUTE), performance
concerns are unnecessary (quantum economics).  This method is suitable
for any physically controlled system.

Unfortunately, Mr. Greenberg's algorithm fails this test because it is
publicly known.  A mechanism designed to subvert his programs is
feasible (worm, trojan, virus, bomb, etc.).  However, given a small
number of different algorithms (ADD/SUB/XOR followed by ROL/ROR/NOP
give nine easily) generated by a machine-unique seed (time hack at
initial algorithm load would work), a non-resident intruder would have
a very hard time subverting a system without generating a few errors
first.

This is particularly effective if even the creator of such a program
cannot predict which algorithm/seed will be used on a particular
machine.

A procedure such as this is even workable in a networked/server
environment: the file itself is stored en clair.  Each authorized user
has a unique signature file.  No two signatures match yet each will
authenticate the same file in the proper machine.  A nightmare for
intruders.

Alternatively, a publicly transmitted file for which the algorithm/key
is also public requires a much more rigorous algorithm to avoid
spoofing or infection by a determined intruder.  In this case ANSI or
DES is appropriate.

Taken together, the indication would be that for inter-machine
transmission, the more rigorous public-key methods would be
appropriate, while a much simpler one would be suitable for
intra-machine retrieval.  This would postulate a software package
that:

a:  Uses a simple (fast) but unique algorithm for known files whose
signatures are stored on the platform.

b:  Requires a much more rigorous authentication process for unknown
files (possibly also requiring authorization for load).

c:  Once (b) is satisfied allows a file to migrate to (a).

Considering the viral threat, if a virus is accompanied by a valid
signature, ANY authentication scheme will pass it, however, as aoon as
a resident file is infected, the unique resident signature will become
invalid.

The point was raised concerning Boot and Partition Table Infectors
(Hidden Sector, FAT, Root, RAM-Resident, and Bad Sector Infectors are
also possible).  This is a different question from that of
authenticating a file.  At present I know of only one package that
provides complete coverage: Enigma-Logic's Virus-Safe which I use.

However, over 90% of all PC virii could have been caught early by a
CLI that occasionally compares the Top-Of-Memory, the end of DOS/TSR
memory, and the first byte of the Boot Sector against known values.
MS-DOS doesn't.

(END OF PADGETT PETERSON POSTING)

Thank You,


Bob Bosen
Enigma Logic Inc.

------------------------------

Date:    Tue, 10 Apr 90 11:39:00 -0500
From:    [e-mail]
Subject: Re: Death of a Virus

A more accurate analogy might be the introduction of clean water
systems rather than the elimination of smallpox.  The widespread use
of modern operating systems with memory and device protection will
greatly hinder the spread of viruses, but by no means prevent their
spread.  I can think of methods to implement Unix and VM viruses.
Most of these depend upon sloppy system administration methods for
rapid spreading, but at least for now sloppy administration is the
norm.  Some of these have been demonstrated by attacks like the
Internet Worm.  But with a more modern hardware and operating system
it is much harder to spread and easier to cure.  This is similar to
what you find today with water-borne diseases.  Typhoid, cholera, and
dysentery are by no means eliminated in the US, but they are no longer
a normal cause of death.  They promptly return after disasters break
down the water systems (well cholera is still rare, but would recur if
the breakdowns lasted long enough).

Probably the greatest strength of most current systems is the
diversity of hardware and operating system revisions.  This forces the
use of source (non-executable) for most inter-machine transfers and
greatly hinders the spread of viruses and worms.  The strong
commercial push for standard binary interfaces is a danger in that it
will greatly increase the size of the computer population that is
vulnerable to any one specific attack.

R Horn  [e-mail]

------------------------------

Date:    10 Apr 90 00:00:00 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: Re: Death of a Virus

[e-mail] (Kelly Goen) writes, apparently in response
to a posting of mine:

> Yes dave but under environments which use say the VM8086 model on
> the 386 (such as VPIX) file writability and/or hardware acces is
> TOTALLY under the control of unix...  weak unix security weak dos
> security good unix security = good dos security in this case....

My point was that putting file access under the control of the
operating system *doesn't help*, at least not as much as people
generally assume.  Viruses spread by writing to files that they are
*allowed* to write to; they don't depend on a lack of security.  If
most programs have write access to only a few other programs, viruses
may not be able to spread as fast; but lowering the exponent on an
exponential spread helps surprisingly little.

Now of course this may be what you were saying; I'm not entirely sure
I understand the posting...

DC

------------------------------

Date:    10 Apr 90 22:44:00 +0000
From:    [e-mail] (Alan L. Pope)
Subject: Re: Universal Virus Detector

A Universal Virus Detector?  Go reread Goedel's Incompleteness Theorem.
                                        Alan Pope <[e-mail]>

------------------------------

Date:    Tue, 10 Apr 90 15:49:57 -0400
From:    [e-mail] (Eloise Kleban)
Subject: FTPing Disinfectant

Someone recently commented on the difficulty of downloading
Disinfectant from Simtel20.  I would say it is easier to
access sumex-aim.stanford.edu for Macintosh software.  Simply
FTP the files in ascii mode (non-binary) to your CMS account,
then download them (again, in ascii) to your Mac.  On the Mac
use Stuffit to decode and un-archive the applications.  I
recently acquired Disinfectant 1.7 this way with no trouble.

Eloise Kleban                     BITNET:   ELOISE@MAINE
Academic Coordinator              INTERNET: [e-mail]
Computing Center                  Phone:    [phone]
University of Maine
Orono, ME, USA 04469

------------------------------

Date:    Tue, 10 Apr 90 22:50:39 +0000
From:    Dave Ihnat <[e-mail]>
Subject: Re: Death of a Virus

[e-mail] (David.M.Chess) writes:
>Unfortunately, viruses do not depend on this hardware model; viruses
>can spread in any system that allows both programming and information
>sharing, regardless of whether or not programs have direct access to
>the hardware, whether or not the system is assumed to be single-user,
>and so on.  See various papers by Fred Cohen on the subject.  As long
>as (roughly) some programs sometimes have write-access to some other
>programs, viruses can spread.
>Dave Chess
>IBM T. J. Watson Research Center

As a practical matter, I was trying to not go into a lecture on the
differences between the hardware and software models you bring up.
But the baseline is this: All of the single-user machines which are
currently the major targets of viral attack provide NO hardware model
which allows preemptive control by the OS or monitor of program access
to memory or hardware.  Thus, in such systems, it is categorically
impossible to provide a reliably virus-free environment.

Systems which provide the underlying hardware CAN be made much more
secure.  In this environment, it is still possible to improperly use
the provided capabilities and thus grant unauthorized access; but this
is not a case of CAN be secure, but DIDN'T make it secure but had the
capability.  As a real- world example, Unix and VMS systems don't see
the widespread attacks that single-user systems such as the PC and Mac
have "enjoyed."  Attacks on such multi-user/multi-tasking systems that
are successful invariably result from either errors in the protection
mechanisms (usually, not the hardware itself, but rather the operating
system which utilizes it) or errors in application of the provided
protections, either by programmers (privileged programs that don't
properly control access, etc.), or by administrators and users who
don't use such capabilities as ACL's and file permission settings.

So the point I was making is that in an environment which doesn't even
provide underlying hardware support for protection, it's impossible to
make a secure, safe system no matter how good you are in software
development.  Having the hardware, however, does not guarantee such
security; but id does make it possible.

------------------------------

Date:    Wed, 11 Apr 90 01:05:41 -0400
From:    *Hobbit* <[e-mail]>
Subject: validation

The best way anyone could validate his antiviral is to distribute the
sources.  Which most of these authors seem highly unwilling to do, for
some odd reason.  Did you ever wonder what they were hiding sometimes?
This exe-file validation stuff is a crock.

_H*

------------------------------

Date:    Wed, 11 Apr 90 08:08:22 -0500
From:    [e-mail]
Subject: False Indications from VIREX 2.5.1 (MAC)

HJC Software, authors of VIREX Virus Detection Software, has confirmed
a bug in their software version 2.5.1, ALL software written in
QuickBasic will give you a false msg of a Trojan Horse being detected.
HJC Software will be releasing version 2.6 shortly which will correct
this problem.  It will be sent to all registered users.

This was brought to my attention by a fellow ham radio operator, O.P.,
KF4TE, who attempted to use a program MacLogger.  I have personally
talked to Chris Lyons, VE3GUS, author of MacLogger and confirmed that
his software WAS written in QuickBasic.

JIM

************** From the Desk of Mr. James M. Vavrina **************
*            Comm 703-355-0010/0011  AV 345-0010-0011             *
* DDN: [e-mail]  AMPR: KA4USE @ KA4USE.VA.USA.NA *
*******************************************************************

------------------------------

Date:    11 Apr 90 12:28:16 +0000
From:    [e-mail] (Nils Hagner)
Subject: Virus on Apollo? (UNIX)

Does anyone know whether any viruses have been found on Apollo
workstations? In that case, are there any available anti-virus tools?

==============================================================
Nils Hagner | UPMAIL: [e-mail]                   |
            | Infologics: [e-mail]                   |
==============================================================

------------------------------

Date:    11 Apr 90 12:55:19 +0000
From:    [e-mail] (SRB)
Subject: Re: Validating Virus Software

In article <see References:> (Gary Mathews) writes:
>In fact, a list of must commonly used programs should be included on
>such a list, but for now the validated strings of the lastest versions
>for the scan and clean programs should be publically accessible.  Many

I always wondered: shouldn't the crc-32 and crc-16 of zip and arc files be
unique enough to validate any file?

Why can't we just put these checks and the length of a file on the net.
If you insist, then of course you could add any propietary validation values
like the ones obtained from the validate program.  But I'm pretty sure that
most people trust their favorite zip or arc program more than some kind
of a so-called validate program.
- --
Sincerely,                         | [e-mail]
           Stephen R. van den Berg | ...!uunet!mcsun!unido!rwthinf!cip-s01!berg

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 13 Apr 1990    Volume 3 : Issue 75

Today's Topics:

Hardware Security
Loophole in VIREX 2.6? (Mac)
Antiviral Validation
Re:Signature Programs
Re: Virus in Text Files (Mac)
Re: validation
Re: Validating Virus Software
Re: Virus in Text Files (Mac)
New (mean) Virus? (PC)
Jerusalem Viri (PC)
Re: Death of a Virus

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 11 Apr 90 15:21:24 -0400
From:    [e-mail]
Subject: Hardware Security

Dave Ihnat <[e-mail]> writes:
>So the point I was making is that in an environment which doesn't even
>provide underlying hardware support for protection, it's impossible to
>make a secure, safe system no matter how good you are in software
>development.  Having the hardware, however, does not guarantee such
>security; but id [sic] does make it possible.

   Having the hardware neither guarantees such security nor makes it
possible; what it does make possible is a greater degree of security,
and that is, in itself, a good thing.  But a completely safe,
completely secure system is impossible unless no changes could be
made.  (If no changes could be made, then, of course, we must ask
ourselves how such a system was brought into being, and then realize
that no such system can exist.)  As long as some changes can be made,
whether they are loopholes due to an imperfect strategy (because even
if the security system could be perfectly implemented, it would also
have to be perfect in its conception), or they are changes that are
considered to be proper under most conditions, then some program could
exploit that ability to make changes and create harmful or virulent
code.  Hardware support for security makes the virus writer's job more
difficult and the virus interceptor's job easier, which, as I said, is
good.  But do not confuse increased security for complete security.

                             Regards,
                             David R. Conrad

+-------------------------------------------------------------------------+
| David R. Conrad           (preferred) [e-mail] |
| /\/\oore Soft\/\/are                  [e-mail]               |
| Disclaimer: No one necessarily shares my views, but anyone is free to.  |
+-------------------------------------------------------------------------+

------------------------------

Date:    Wed, 11 Apr 90 15:31:16 -0400
From:    [e-mail]
Subject: Loophole in VIREX 2.6? (Mac)

Mr. James M. Vavrina writes:
>From:    [e-mail]
>Subject: False Indications from VIREX 2.5.1 (MAC)
>
>HJC Software, authors of VIREX Virus Detection Software, has confirmed
>a bug in their software version 2.5.1, ALL software written in
>QuickBasic will give you a false msg of a Trojan Horse being detected.
>HJC Software will be releasing version 2.6 shortly which will correct
>this problem.  It will be sent to all registered users.

   I wonder if this is a problem with VIREX or an anomaly in QuickBasic?
It could be the case that, in the future, any trojan which emulates the
structure of a QB object will be passed over by VIREX, creating a loophole
similar to the one created by checking the "Always Compile MPW INITs" box
in Vaccine.

+-------------------------------------------------------------------------+
| David R. Conrad           (preferred) [e-mail] |
| /\/\oore Soft\/\/are                  [e-mail]               |
| Disclaimer: No one necessarily shares my views, but anyone is free to.  |
+-------------------------------------------------------------------------+

------------------------------

Date:    Wed, 11 Apr 90 15:50:14 -0400
From:    [e-mail]
Subject: Antiviral Validation

Stephen R. van den Berg writes:
>From:    [e-mail] (SRB)
>Subject: Re: Validating Virus Software
>
>I always wondered: shouldn't the crc-32 and crc-16 of zip and arc files be
>unique enough to validate any file?
>
>Why can't we just put these checks and the length of a file on the net.
>If you insist, then of course you could add any propietary validation values
>like the ones obtained from the validate program.  But I'm pretty sure that
>most people trust their favorite zip or arc program more than some kind
>of a so-called validate program.

   The problem with this plan lies in that the CRC algorithms used by
these archive programs are public knowledge, and it is very easy to
arrange for a file to have a specific CRC value.  Publishing the file
size in addition to the CRC value makes the problem harder, since one
can't simply add inert data to the end of the file to finagle the CRC
value, but even this doesn't provide sufficient protection, since some
of the data in the file may be safely changed (perhaps a statically
allocated buffer), or, in extreme cases, a dedicated virus writer
could sacrifice some rarely-used routine in the target program.
Proprietary validation routines provide slightly better security,
since the algo- rithm is not public information, but once again a
dedicated virus writer could reverse-engineer the algorithm from the
validation program itself.  The best solution at this time is to use
validation algorithms from which it is computationally infeasable to
produce a specific value.  Snefru 2.0 and MD4 are two good examples.

                             Regards,
                             David R. Conrad

P.S. Snefru 2.0 is The Xerox Secure Hash Function.  I seem to recall that
  the author of MD4 requested that it be referred to by some specific
  name, but the name itself I have forgotten.  My apologies.

+-------------------------------------------------------------------------+
| David R. Conrad           (preferred) [e-mail] |
| /\/\oore Soft\/\/are                  [e-mail]               |
| Disclaimer: No one necessarily shares my views, but anyone is free to.  |
+-------------------------------------------------------------------------+

------------------------------

Date:    Wed, 11 Apr 90 16:08:48 -0500
From:    utoday![e-mail] (Ross M. Greenberg)
Subject: Re:Signature Programs

>My personal feeling is that an authentication algorithm may be very
>simple (CRC or less) provided that it is unknown (or unpredictable).
>Since my 4.77 Mhz/ST-412 museum piece is capable of a simple byte
>count/XOR/ROR disk file check at 50k bytes/second (and could be faster
>if done in RAM by a TSR between LORD and EXECUTE), performance
>concerns are unnecessary (quantum economics).  This method is suitable
>for any physically controlled system.
>
>Unfortunately, Mr. Greenberg's algorithm fails this test because it is
>publicly known.  A mechanism designed to subvert his programs is
>feasible (worm, trojan, virus, bomb, etc.).  However, given a small
>number of different algorithms (ADD/SUB/XOR followed by ROL/ROR/NOP
>give nine easily) generated by a machine-unique seed (time hack at
>initial algorithm load would work), a non-resident intruder would have
>a very hard time subverting a system without generating a few errors
>first.

Sorry: although it would be easy to ascertain via disassembly the
particluar method I use in my code for generating a signature, I would
hope that the bad guys are as easily fooled by someone using the word
"Checksum" or "CRC" as you were.  <Gotcha! Heheheh> My signature code
stuff is proprietary and has never been released to anyone.  I use the
word "checksum" or "CRC" loosely because it's easier to say than "an
assortment of instructions that merely generate a unique number based
upon a stream of input with no real formal basis for figuring out just
how good the particular algorithm issince it seems good enough so
far."

>This is particularly effective if even the creator of such a program
>cannot predict which algorithm/seed will be used on a particular
>machine.

I may include such a random seed in the future, but it seems pretty
easy to be able to determine that seed and therefore why bother?
Remember that DOS isn;t really an operating system anyway and it would
be pretty easy for someone to subvert *any* signature generating code
easily. Better still would be to use two differing algorithms that
combine into one unique signature.

>However, over 90% of all PC virii could have been caught early by a
>CLI that occasionally compares the Top-Of-Memory, the end of DOS/TSR
>memory, and the first byte of the Boot Sector against known values.
>MS-DOS doesn't.

Fascinating number, that 90%.  No justification for it from what I can
see.  And your statement on the Boot Sector's first byte being the
important one to check is totally wrong.  If you could send me the
background on that number, I'd apreciate it.  I believe none of the
numbers I see bandied about regarding viruses.  Too easy to slip a
decimal point or two, or to extrapolate from a limited subset.

Mr. Peterson makes some interesting points.  They do not, however,
seem conclusive to me.  I stand by my earlier statements that a simple
algorithm for CRC/signature/checksum checks is "good enough".

Ross M. Greenberg,     Software Concepts Design,    [e-mail]
             594 Third Avenue, New York, New York, 10016
 Voice:(212)-889-6431 BIX: greenber  MCI: greenber   CIS: 72461,3212
                            BBS:(212)-889-6438

------------------------------

Date:    10 Apr 90 23:19:34 +0000
From:    [e-mail] (Carol K. Kellogg)
Subject: Re: Virus in Text Files (Mac)

In article 2076, [e-mail] (Woody Baker @ Eagle
Signal) said, in part...
 >Macintosh datafiles, as I understand them, have 2 parts, a resource
 >fork and a data fork.  Anything in resource fork (so I've been told)
 >can execute.  Does this imply that one could bury a virus in the
 >resource fork of a data file?  >

Arrrgh...more Macintosh Myths.

First, one minor correction..."the resource fork of a data file" is an
oxymoron - data file usually implies information stored in the data
fork (which is non-executable), and a resource file implies a file in
which the information is stored in the resource fork (SOME of which is
exexcutable).

Not _EVERYTHING_ in the resource fork can be executed - only
executable resources, such as CODE (actual program code) resources,
WDEF (window definition), INIT (startup "terminate and stay resident"
type of code), etc.

The ONLY way to infect a Mac file is to put a virus in one of these
executable resources.  Many viruses add their own CODE resource, and
then patch the jump table so that they're executed before the rest of
the application.

There is one virus that spreads infections via WDEF resources, but its
fairly easy to guard against.

Disinfectant (an excellent virus protection/repair) utility deals
effectively with all the known viruses on the Mac.

>Woody

Lars Kellogg-Stedman
[e-mail]

------------------------------

Date:    12 Apr 90 03:49:01 +0000
From:    [e-mail] (The Wanderer)
Subject: Re: validation

[e-mail] (*Hobbit*) writes:
>The best way anyone could validate his antiviral is to distribute the
>sources.  Which most of these authors seem highly unwilling to do, for
>some odd reason.  Did you ever wonder what they were hiding sometimes?
>This exe-file validation stuff is a crock.
>
>_H*

     I don't think this is a valid argument, for at least three reasons.
     1) SCANRES, SCAN, et al are *commercial* programs.  Commercial programs
do not generally have their source code distributed; that is a simple fact of
the industry.  We can argue the merits of free software all day and it won't
change that.  Take your argument to its logical conclusion:  The lab where I
work uses Microsoft Word for word processing.  We would be just as damaged if
we were to receive a virus-infected copy of Word that if we were to receive a
virus-infected copy of SCAN.  Therefore, we should expect Microsoft to supply
complete source to Word with every update of their program, so we can compile
Word ourselves and avoid any possible contamination of their masters.  I don't
see this happening.  (I don't see why it should...  I for one would not care to
have to keep a copy of every language ever written around just in case some
program I wanted to use happened to be written in it.  And if you're not going
to recompile from the source, what's the good of having it?  How do you know
the executables contain the same code as the source?)
     2) Source would be absolutely useless to 99%+ of the program's users.
If someone were to hand me a copy of, say, SCAN source, and say "Two lines of
this code will destroy your hard disk.  Find them," I wouldn't know where to
begin; I don't know enough about low-level file access to tell the normal calls
from the destructive ones, and I consider myself a pretty darn good programmer.
And that's assuming the destructive code was written in a straightforward
fashion; ever read the Obfuscated C contest?  (And the SCAN programs are
relatively small; you could hide a battleship in, say, the Word source...)
     3) Such a listing, however, would be *extremely* useful to 99%+ of the
virus writers out there.  Given exact knowledge of how a virus-checking routine
works, writing a counter-routine specifically designed to evade or disable it
is trivial.  Let the virus writers at least go through the work of
disassembling the executable; it won't stop 'em, but it'll slow 'em down at
any rate.
- --
Internet: [e-mail]        (University of Washington, Seattle)
  The views expressed here are not those of this station or its management.
   "If you can keep your head while those about you are losing theirs,
      consider an exciting career as a guillotine operator!"

------------------------------

Date:    12 Apr 90 06:30:57 +0000
From:    nixpbe![e-mail] (gla)
Subject: Re: Validating Virus Software

[e-mail] (David Ward -- Computer Support/Special Needs) writes:

>Periodically we hear concerns about the validity of SCANVxx and other
>antiviral programs.  I think these concerns are valid since a
>virmentor creating a virus would likely take great joy in attaching
>the virus software to a product designed to fight viruses.
>...
>A simple solution to this problem is that when new versions of scan
>are announced on this digest, the announcement should include the
>validation strings given by McAfee.  Then we can download from any
>local source and compare the strings published in Virus-L to
>those we generate with the validate program.

The problem adressed here is well-known: we need a MAC, a message
authentication code. It means that you can check the checksum by using
a public known key of the author.  The first system usable for this is
the RSA public key encryption system. For a MAC, you encrypt the
checksum with the privat key of the author and append it to the
message. It can be decrypted by anyone using the public key which has
to be obtained once, and then the checksum can be checked.
Unfortunately, it is patent copyrithed in USA and requires lengthy
computations of prime numbers for the keys, and depends both on the
problem of factorisation and the discrete logarithm.

But there is an alternative scheme: the ElGamal-Scheme. It requires
modulo arithmetic and depends only on the discrete logarithm problem,
and it is - to my knowledge - not protected. To check the signature,
the calculations are somewhat longer than for RSA; to obtain the
signature, an equation has to be solved which is straighforward using
Euclid's algorithm, extended.

For the original description, see: ElGamal, T.: A Public Key Cryptosystem
and a Signature Scheme Based on Discrete Logarithms. IEEE Trans. Inf.
Theory, Vol. 31, No. 7, 1985, pp. 469-472.

Rainer Glaschick, Nixdorf Computers, Paderborn, W-Germany
EMail: [e-mail]  or  !uunet!nixbur!glaschick.pad
Phone: [phone]  (absent till April 23)

------------------------------

Date:    11 Apr 90 13:49:10 +0000
From:    [e-mail] (Robert J Woodhead)
Subject: Re: Virus in Text Files (Mac)


[e-mail] (Woody Baker @ Eagle Signal) writes:

>Macintosh datafiles, as I understand them, have 2 parts, a resource
>fork and a data fork.  Anything in resource fork (so I've been told)
>can execute.  Does this imply that one could bury a virus in the
>resource fork of a data file?

>I'm sure that this has been hashed over before.
>Cheers
>Woody

Not quite.  Resource forks contain resources.  Some resources are "code-
bearing" resources, some are data.  Only code bearing resources could
ever get executed.  However, for this to happen, the system (or an app)
has to decide it wants to do so.  For a variety of technical reasons,
it is extremely unlikely that this can be induced to occur.  It might be
possible to write a virus that infects a certain application only and
once in that app can spread to others (that piggybacks on that target
app's documents) but it would be an unreliable and difficult infection
vector.

Summary : very difficult, unreliable, not bloody likely

PS: a semi-example of this "piggybacking" is WDEF, which depends on a
quirk of the OS to get executed if it is in the desktop file.  However,
the desktop file is a very special file on a macintosh.
- --
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!

------------------------------

Date:    Thu, 12 Apr 90 13:32:16 -0700
From:    Peter Sturdee <[e-mail]>
Subject: New (mean) Virus? (PC)

    A friend of mine sent me this request for information.  I, not knowing
    the answer, am forwarding it to you people.  The entire message
    follows.  Replies can be sent to me.

    Thanks, alot, really,
    Peter Sturdee

- ------< Start of message >------

From:     DECPA::"[e-mail]" "Alex Lopez-Ortiz" 12-APR
\c-1
990
 15:46:16.17
To:       troa02::sturdee
Subj:     Virus Attack!

Pete,

  Do you know of a virus that does this?

Wipes Boot sector on "C" Drive to 0's
Erases every directory entry (including subdirecty entries)
from every directory of the disk (by puting the Delete char as
first character in the file/directory name)

Kills all FAT copies on "C" drive
changes the date and size of IBM PC-DOS V3.3 from 25307 -> 25324 (increase)
and dates from 3-17-87 to 11-27-89 at 12:00.

We recovered the machine with Norton and PCTools.. but a virus scan
doesn't get anything.. mind you we might not have the latest edition
of the scanner...

Have you read anything about this type of one?  We still can't figure out
what program spawed the virus.

Alex

- ------< End of message >------

------------------------------

Date:    Thu, 12 Apr 90 18:53:30 +0000
From:    [e-mail] (Henry A. Rowley)
Subject: Jerusalem Viri (PC)

The undergraduate student laboratories in the Electrical Engineering
Department at the University of Minnesota have been infected
with the Jerusalem virus.  I think the specific strain in Jerusalem
B.  I plan to write a program that will detect when the viruses
are infecting the machines (as opposed to cleaning up afterwards).

Does anyone have any information about how the Jerusalem viri work?
Such information as file signatures, infection methods, cleanup
methods, and disassembled code would be greatly appreciated.

Please send any responses through E-mail, and I will post a summary
in this news group if there is any interest.

Thanks in advance.

Henry A. Rowley                   [e-mail]

- --
Henry A. Rowley         [e-mail]
"Don't Panic!"

------------------------------

Date:    13 Apr 90 10:19:01 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: Death of a Virus

[e-mail] (David.M.Chess) writes:
>[e-mail] (Kelly Goen) writes, apparently in response
>to a posting of mine:
>
>> Yes dave but under environments which use say the VM8086 model on
>> the 386 (such as VPIX) file writability and/or hardware acces is
>> TOTALLY under the control of unix...  weak unix security weak dos
>> security good unix security = good dos security in this case....
>
>My point was that putting file access under the control of the
>operating system *doesn't help*, at least not as much as people
>generally assume.  Viruses spread by writing to files that they are
>*allowed* to write to; they don't depend on a lack of security.  If
>most programs have write access to only a few other programs, viruses
>may not be able to spread as fast; but lowering the exponent on an
>exponential spread helps surprisingly little.
>
>Now of course this may be what you were saying; I'm not entirely sure
>I understand the posting...
>
>DC

Well close dave what I was referring to is the running of DOS programs
in a virtual environment and preventing access to hardware models or
real "Anything..." Viruses written to attack MS-DOS only or the
Hardware model under which MS-DOS functions will fail to infect under
such an environment.... That is what I was trying to say... of course
the platform itself is vunerable to infections native to it...*nix
that is...  so the security is only for now(i.e. temporary..)
   cheers
   kelly

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 16 Apr 1990    Volume 3 : Issue 76

Today's Topics:

Disinfectant 1.7 (Mac)
MACs for Programs
Re: Death of a Virus
Friday the 13th of April Computer Virus??? (PC)
Re: Virus in Text Files
First computer virus extinct?
WDEF A on Chessmaster 2100 and Cribgin (Mac)
Re: Loophole in VIREX 2.6? (Mac)
Jerusalem-B Virus (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 13 Apr 90 15:02:44 -0500
From:    Norbert Bornfeld <[e-mail]>
Subject: Disinfectant 1.7 (Mac)

I have major problems downloading the binhexed 1.7 version from the info-mac
archives as well as from the anti-virus sites as described in this list.
The file seems to be corrupted and decoding the file I get an
EOF-error message. Any solutions?
N. Bornfeld, University of Essen


------------------------------

Date:    Fri, 13 Apr 90 11:44:00 -0400
From:    [e-mail]
Subject: MACs for Programs

>The first system usable for this is
>the RSA public key encryption system. For a MAC, you encrypt the
>checksum with the privat key of the author and append it to the
>message. It can be decrypted by anyone using the public key which has
>to be obtained once, and then the checksum can be checked.
>Unfortunately, it is patent copyrithed (sic)in USA .....

It is true that RSA is protected by patent and copy right in the U.S.
However, I am not prepared to grant that that is "unfortunate," or somehow
removes it from consideration.

>and requires lengthy
>computations of prime numbers for the keys, ....

Again, true but irrelevant.  If you were going to perform a function often,
its speed would be important.  However, the key is only computed once, by
the originator; even if it takes minutes, who cares.

>and depends both on the
>problem of factorisation and the discrete logarithm.

And, once more, irrelevant, unless, of course your interest is only in
promoting an alternative.

>But there is an alternative scheme: the ElGamal-Scheme.

But of course.  Indeed, there are several.   Let us not forget the
Xerox Secure Hash Function (Snefru).

Incidentally, the sponsor of this algorithm admits that it might be a
little slower than RSA at checking time.   Right!  RSA is slow at key
generation, fast at calculating the signature, which is done more often,
and very fast at checking the data against the signature, which is done
most often.

Any number of existing and theroretical functions will enable us to
determine that the probability of change is vanishingly small, at
least as long as we have a trusted source for the MAC.  However, RSA
has the advantage of providing for attribution of both origin and, if
each person in the chain adds his signature, any change.

All that having been said, the important thing is to start using something.
Part of the reason that we have not done so is that we insist upon seeing
the value as the receiver not running something that he does not intend.
On the other hand, if such a function were available, most people would
not calculate it before running the code.

The real value is in an author not being held accountable for something
that he did not write.  Given the potential for someone adding a virus
to my code, I would not write code for publication where I did not
compute such a value and publish it at least as widely as the code.
Then, if as has happened to readers of this list, someone was damaged
by code that he thought to be mine, but which had been subsequently
maliciously modified, I would be able to demonstrate that the code
used was not the same as what I shipped.  I would be protected even if
the end user, who failed to compute my function, was not protected.

Authors, the use of a MAC serves you even if no one ever reconciles it.
It is cheap.  You have a choice of functions, security, and costs.  The
choice is yours.  Pick one, but do something.  Use several; they are
cheap.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    12 Apr 90 00:00:00 -0500
From:    "David.M..Chess" <[e-mail]>
Subject: Re: Death of a Virus

Dave Ihnat <[e-mail]> writes various things, including:

> Systems which provide the underlying hardware CAN be made much more
> secure.

>               Attacks on such multi-user/multi-tasking systems that
> are successful invariably result from either errors in the protection
> mechanisms (usually, not the hardware itself, but rather the operating
> system which utilizes it) or errors in application of the provided
> protections, either by programmers (privileged programs that don't
> properly control access, etc.), or by administrators and users who
> don't use such capabilities as ACL's and file permission settings.

I agree completely with the first; systems with no concept of security
are in general much harder to write reliable anti-virus software for
than systems that provide a trusted kernel, or rings, or other ways
to protect some software from other software.

I disagree with the second, though; unless you label any setting of
access levels that allows some programs to write to others as
an "error", viruses can spread even in systems that have reliable
access controls which are being used properly and without error.
How many installations can you think of where no program *ever*
legitimately writes to another?

I think the reasons that we have seen microcomputer viruses, but no
large-system viruses are primarily "cultural" (writing viruses hasn't
become "the thing to do" in the mainframe underground, there simply
aren't as many mainframe programmers, large installations don't tend
to exchange software yet, and so on).

DC

------------------------------

Date:    13 Apr 90 18:19:15 +0000
From:    [e-mail] (Marilyn Bushway)
Subject: Friday the 13th of April Computer Virus??? (PC)

Hello we are experiencing what we believe to be a virus.  It just hit
today.  Symptoms: All executable files are destroyed and must be
reloaded.  It is only on P.C.'s (Dos machines) It just hit the campus
today which is Friday the 13th.  Is there a virus out there that we
didn't know about???  Does anyone know of a utility for ridding the
machine of it.

[e-mail]

- --
Marilyn Bushway  3181 S.W. Sam Jackson Park Rd. Portland, OR  97201
[phone]   {ogicse,qiclab,uunet,tektronix,nosun,psueea} ohsuhcx!mkb

------------------------------

Date:    Fri, 13 Apr 90 23:35:06 +0000
From:    rutgers!tiger.ecn.purdue.edu![e-mail] (Ashar Nisar)
Subject: Re: Virus in Text Files

cdss![e-mail] (Tom Culliton) writes:
>[e-mail] (Dr. Ruth Mazo Karras) writes:
>
>How many times has this question been answered?  If you can't execute
>the file or run it via an interpreter it can't carry a virus.  If its

That is a very general statement.... and flase too!

Technically yes you may be right... but you never know if somebody
can't exploit any bug in the systems software to get the control of
the machine... even when APPARENLY the system is just READING a text
file etc.

An example is the Internet worm that used a bug in mail system Now
mail system apparently only reads/sends text mail.... and there is no
reason why such a bug can not exist in current PC software, especially
with so many third party Network/LAN/mail/tcp etc implementations

Not likely, BUT there is NO guarantee

- -ashar

[e-mail]

------------------------------

Date:    Sat, 14 Apr 90 00:53:22 -0700
From:    [e-mail] (Joe Dellinger)
Subject: First computer virus extinct?

In article <[e-mail]> [e-mail] (Per Lindberg) writes:
>He he... Single-host viruses dies out when their host dies out.
>Will this be the first COMPUTER virus destined for extinction?
>Why isn't the WWF doing anything!!??

Well, there is an interesting point here: Macintoshes and IBM PC's seem to
be CRAWLING with many strains of viruses. One person on comp.virus reported
a single file infected with three viruses simultaneously! On the other hand,
it seems viruses on Apple ]['s were pretty rare. A few existed, including
mine, but none of them ever seems to have reached anywhere near epidemic
proportions. Most Apple ][ users I've heard back from report NEVER
encountering _any_ viruses.

What's the difference? An Apple ][ was an ideal machine to write a virus
for. There was massive copying of software. There's been plenty of
time for viruses to have become entrenched. Why didn't they? My guess is that
the proliferation of non-standard DOS's (I never realized there were so many
DOS variants in common use out there. Dozens of them. Wow!) and the LACK of
standard methods of interfacing with the OS (such as it was) are responsible.
Most viruses are _extremely_ host-specific, where "host" means both the
hardware AND the OS.

Can we infer the general rule that a heterogeneous software population is the
best deterrent to runaway infection? (After all, people have a large number
of different HLa types. Why? Smallpox is much deadlier for people with blood
type "A" than "O". Why are there any people with bloodtype "A" still around?)
Our computer's non-standard "fingd" did not fall prey to Morris' internet
worm, even though it works fine as a "fingd". My point is that worms and
viruses usually depend on a lot of things being exactly a certain way.
Good network programs, on the other hand, can only assume the bare minimum
protocols defined in the RFCs. There may be some escape hatch like Berkeley
sendmail's "debug" option, but only ONE "genotype" of sendmail program fell
prey to that attack.


------------------------------

Date:    Sat, 14 Apr 90 05:11:28 -0700
From:    [e-mail]
Subject: WDEF A on Chessmaster 2100 and Cribgin (Mac)

VIRUS-L V3 #72 (9 Apr) contained an unconfirmed report that Chessmaster
2100 (Macintosh version) from the Software Toolworks was infected with
WDEF A.  The Toolworks was looking into it.

I contacted them Tuesday, and they have confirmed that WDEF A was on
their master disks for both Chessmaster 2100 and another game program
called Cribgin, both for the Mac.  They have started a recall on both
products, and expect to be able to ship replacements starting this Friday.

          Jim Gillogly
          [e-mail]

------------------------------

Date:    15 Apr 90 15:32:57 +0000
From:    [e-mail] (Robert J Woodhead)
Subject: Re: Loophole in VIREX 2.6? (Mac)

[e-mail] writes:

>   I wonder if this is a problem with VIREX or an anomaly in QuickBasic?
>It could be the case that, in the future, any trojan which emulates the
>structure of a QB object will be passed over by VIREX, creating a loophole
>similar to the one created by checking the "Always Compile MPW INITs" box
>in Vaccine.

No.  The problem was that, not having another example of a QuickBasic
program handy, the signature used in 2.51 unfortunately matched every
QB program.  This was an easy fix.

Thanks for the concern though.

- --
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!

------------------------------

Date:    16 Apr 90 08:41:55 +0000
From:    inesc![e-mail] (Julio Raposo)
Subject: Jerusalem-B Virus (PC)

          I have made last year a program to clean the Jerusalem-B virus from
  the infected files without damaging them. I've done this because at the
  time the only other method I had was just deleting the files and restoring
  them from the backups. A few days after I got my hands on John McAfee's
  programs (Oh dear, I haven't got his name anywhere near by, please forgive
  me if I misspelled it) and decided I would go on working on my own
  program, VKILL. The version 1.0 is available from SIMTEL among other
  places, both C-source and compiled program with the Turbo-C init and
  project files.

          The reasons why I say that for me my program is better than SCAN and
  CLEAN are:

          Here the infections are mainly by Jerusalem-B virus (I don't know
                    why). After using VKILL, most of the disks are reported
                    clean by SCAN.

          VKILL is very fast because it looks for the only place in the file
                    the virus usually is. It only fails if other trash has been
                    appended to the file after it has been infected.


          Now I am working on the new version of VKILL. This new version is
  able not only of cleaning the virus but can also make all the files immune
  to new attacks. The next release will be 1.2, 1.1 being the Beta test
  version. When this new version is ready I'll send it to Keith Petersen
  (SIMTEL) and to Bill Davidsen (comp.binaries.ibm.pc postings).

          Meanwhile if someone wants more information about Jerusalem-B or the
  VKILL program, or has found any bug or inconvenience in the use of VKILL,
  please e-mail to me.

- -------
                                        Antonio Julio Raposo
                              ([e-mail] - LISBOA - PORTUGAL)

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 18 Apr 1990    Volume 3 : Issue 77

Today's Topics:

Computer Security/Virus Conference Announcement
Re: WDEF A on Chessmaster 2100 and Cribgin (Mac)
MACs for programs
New files on MIBSRV (PC)
HELP!!! Twelve tricks trojan popped up! (PC)
PCs v. Mainframes
Re: Jerusalem-B (PC)
Mainframe virus activity
Hardware protection and the spread of viruses (PC)
Jerusalem B Virus found at Rutgers U (PC)
Detecting "smart" viruses

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with yourreal nme.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 16 Apr 90 08:25:22 -0500
From:    [e-mail] (Tim Ramsey)
Subject: Computer Security/Virus Conference Announcement

[ I'm posting this for a faculty member.  Please direct all questions
  and comments to the address given below. ]

Nobol Computer Servicers, Inc. is presenting a seminar on Computer and
Information Security to be held at the Embassy Suites hotel at the Kansas
City International Airport, Kansas City, Missouri  July 11-13.
The topics to be covered by experts from business, industry, government and
academia are: database security, network security, data center security,
risk management, contingency planning, EDP auditing, computer crime,
malicious code (viruses, trojan horses, worms, etc.) and the security and
integrity of data.  The seminar sessions will be grouped into three tracks
each day and participants are free to move from track to track. Panel
sessions will occupy the third day; discussion time will be allotted in
those sessions for attendees to raise questions requiring indepth answers.

Seminar speakers include Jay Bloombecker, Director of the National Center
for Computer Crime Data; Clay Hodson, Supervising investigator for the
Economic Crime Unit in Riverside California; Ed Devlin, Executive Vice
President of Harris, Devlin and Associates, consultants in disaster recovery
and business resumption planning; Carol Brown, Vice President of Winthrop,
Brown and Co., a former systems programming manager and author of books for
senior management on computing; and Computer Associates will discuss security
in the DB2 system.

For more information contact:
Nobol Computer Services, Inc.
Attn: David Spore
414 NW 66th Terrace #204
Kansas City, MO 64118

------------------------------

Date:    Mon, 16 Apr 90 17:44:47 +0000
From:    [e-mail] (Tasuki Hirata)
Subject: Re: WDEF A on Chessmaster 2100 and Cribgin (Mac)

[e-mail] writes:
>VIRUS-L V3 #72 (9 Apr) contained an unconfirmed report that Chessmaster
>2100 (Macintosh version) from the Software Toolworks was infected with
>WDEF A.  The Toolworks was looking into it.
>
>I contacted them Tuesday, and they have confirmed that WDEF A was on
>their master disks for both Chessmaster 2100 and another game program
>called Cribgin, both for the Mac.  They have started a recall on both
>products, and expect to be able to ship replacements starting this Friday.
>
>         Jim Gillogly
>         [e-mail]

To those of you that complain about the virus will recieve a complementary
copy of Virex.....

- --
/ Tasuki Hirata ([e-mail]) | Intel 80386:                  /
/ UUCP: uunet!eng.umd.edu!sukes     | Power Tool for the Power Fool /

------------------------------

Date:    16 Apr 90 11:03:39 -0400
From:    Bob Bosen <[e-mail]>
Subject: MACs for programs

>From V3 #76 (Bill Murray)

>The real value is in an author not being held accountable for
>something he did not write..... Authors, the use of a MAC serves
>you even if no one ever reconciles it. It is cheap. You have a
>choice of functions, security, and costs. The choice is yours.
>Pick one, but do something. Use several; they are cheap.

AMEN! I couldn't have said it better myself. Not that this is the
ONLY good reason to use a sophisticated authentication algorithm, but
it is one MORE good reason.

Please add to the list of available algorithms ANSI X9.9 and ISO
8731-2.

What may not be obvious is that the best of these MAC algorithms allow
the author of a program to publish the selected algorithm, the
signature of his program, AND the cryptographic key used to generate
that signature.

- -Bob Bosen-
Enigma Logic Inc.
INTERNET: [e-mail]

------------------------------

Date:    Mon, 16 Apr 90 12:24:33 -0500
From:    James Ford <[e-mail]>
Subject: New files on MIBSRV (PC)

I have found 2 files which I have placed on MIBSRV.  These files are
DEZIPINC.ZIP and UNZIP20.ZIP.  They unZIP files and have the source
(in C) included.  Hopefully, someone can use them as a jumping-off
platform for developing a CMS, VMS, UNIX (etc.) generic unZIPper.  If
someone takes the plunge (or challenge), I would appreciate a copy of
their program, either by Email or FTPing to
pub/ibm-antivirus/00uploads.  If other OS versions of unZIP are
available now, I would like to know where I can get a copy.

If you don't have a PC, then let me know and I'll mail the C source to
you directly.


At MIBSRV.MIB.ENG.UA.EDU (130.160.20.80),
located in pub/ibm-antivirus
- ----------------------------
DEZIPINC.ZIP - 27619 bytes
UNZIP20.ZIP  - 46138 bytes


- ----------
Buy in haste, repair at leisure.
- ----------
James Ford -  [e-mail], [e-mail]
              THE University of Alabama (in Tuscaloosa, Alabama  USA)

------------------------------

Date:    Tue, 17 Apr 90 09:04:00 +0700
From:    Jeroen Houtzager <[e-mail]>
Subject: HELP!!! Twelve tricks trojan popped up! (PC)

Hello,

A friend discovered the "Twelve Tricks Trojan" on his 386 machine.

What can he do to get rid of this thing? He knows which floppy imported
it and he has a backup. But the damn thing seems to hide everywhere!!!

Questions:

        - Does the TTT hide in CMOS RAM?
        - Does the TTT hide in EMS RAM?
        - Does the TTT infect OS/2 programs?
        - How can infected files be repaired?

Please reply as quick as possible. My friend doesn't dare to use his machine
and he has to do some project on it...

Thanks in advance for the info!!!

Jeroen

------------------------------

Date:    Mon, 16 Apr 90 17:10:00 -0400
From:    [e-mail]
Subject: PCs v. Mainframes

>I think the reasons that we have seen microcomputer viruses, but no
>large-system viruses are primarily "cultural" (writing viruses hasn't
>become "the thing to do" in the mainframe underground, there simply
>aren't as many mainframe programmers, large installations don't tend
>to exchange software yet, and so on).

I would like to think that Dave is right and that mainframes are
simply more orderly.  In fact, I think that they are simply less
populous.  Depending in part upon the latency and speed of propagation,
viruses require large populations for success (being defined as the
ability to continue to live and propogate).

Think of a population of one, or even a hundred.  Everyone gets sick,
becomes immune, or dies.  Herpes Simplex (chicken pox) will die of its
own weight in populations of less than a hundred thousand.  In larger
populations the population refreshes itself at a rate sufficient to
give the Herpes new places (children) to infect.

>  .................................., large installations don't tend
>to exchange software yet, and so on).

seems to suggest that software is the vector.  That is, that it is the
intent to share software that is causing the spread and success of the
PC viruses.  I do not believe that either.   While this may contribute a
a little, it is really the sharing of MACHINES that is causing the
majority of the spread.  Neither software nor media are being shared
in a way that would cause this problem, but machines are.  That is why
the problem is so much more obvious in labs, centers, and retail outlets.

People are downloading software, and that is risky behavior, but it is
not accounting for much of the spread.   There is even a little sharing of
diskettes, but most people keep their own.   While most machines are
dedicated to a user and not being shared, a large number are being
shared and they are at the nexus of the problem.

Large installations do share software.  They even have bulletin boards.
They move data and programs back and forth.  What they do not do is
take ipl media from one system to another.  They are also pretty good
about managing "write protect" rings.

We need to stop sharing PCs in such a way that nobody is primarily
responsible for their content (the machine's).  We must stop inserting our
media in strange machines, and then taking it to other machines.  When
we must engage in these risky practices, we must employ write protection.

If mainframe populations were as large as PC populations, and if we
moved the media in a similar manner, then we might see the same
problems there as we do in PCs.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    Tue, 17 Apr 90 13:19:54 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Jerusalem-B (PC)

inesc![e-mail] (Julio Raposo) writes:
>         I have made last year a program to clean the Jerusalem-B virus from
>  the infected files without damaging them.

Just one problem - it is not always possible to detect if the program
has been damaged beyond repair by the virus.  This may happen if the
information on the length of the file which is stored in the header is
incorrect.

If it is more than 1808 bytes too low, the corruption can be detected, but
the file should be restored from a backup.

If it is incorrect, but by less than 1808 bytes, the corruption can not be
detected.  So be careful, when repairing Jerusalem-infected files - you cannot
be sure they are restored to their original condition.

This situation is very rare, however - I only know of two examples, one
small utility and WordPerfect 4.x

- --
Fridrik Skulason      University of Iceland  |
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: [e-mail]    Fax: [phone]  |

------------------------------

Date:    Tue, 17 Apr 90 16:07:33 -0400
From:    Arthur Gutowski <[e-mail]>
Subject: Mainframe virus activity

Dave Chess writes:

>I think the reasons that we have seen microcomputer viruses, but no
>large-system viruses are primarily "cultural" (writing viruses hasn't
>become "the thing to do" in the mainframe underground, there simply
>aren't as many mainframe programmers, large installations don't tend
>to exchange software yet, and so on).

I don't think this is entirely what's stopping people from taking an
interest in mainframe virus writing.  True, there aren't as many
mainframe programmers, and true large installations don't trade software
(this is mainly due to most mainframe software being *licensed, commercial*
products--trading is against the rules; and even most in-house development
becomes property of the installation).  But even if there was a fair amount
of trading going on and there were more people in the business...

Writing mainframe viruses is not as simplistic a task is it is for the
micro environment.  Mainframe OS (such as MVS, VM, *nix, VMS) are
extremely complex--they have been under development for more than 20
years.  The knowledge required to program a virus into a system such
as this would be equivalent to the qualifications needed for a System
Programmer.  Not to mention security systems (such as ACF2 or RACF for
VM or MVS).  To be able to romp over someone's programs would require
that you either had write access to his libraries via rules or could
program around the security system.  And this still doesn't mean that
you'll be able to cover your tracks.  At least in MVS there are
records kept of when files are opened, written to, etc.  The
possibility of getting caught far outweighs the novelty or bragging
rights, I think.

Trojans, however, are a different story.  Unfortunately, exploitation of
mail systems (the CHRISTMA EXEC is a prime example), and other system
anomolies is a little easier to accomplish.  I have the misfortune (and
according reputation) for inadvertantly releasing a bomb on MVS simply
(or so I thought) by making a copy of the system catalogs.  It took two
weeks to clean up the mess.  Getting something like this to propogate and
act like a virus is another thing.

I don't think viruses are as much cultural as they are limited by the
complexity of the system(s) involved.

Disclaimer:  These are only opinions.  As such, they are subject to change.
             Any replies and further discussion is appreciated.

  /=====\   Arthur J. Gutowski, System Programmer
 :  o o  :  MVS and Antiviral Group / Tech Support / WSU Univ. Computing Center
 :       :  5925 Woodward; Detroit MI  48202; PH#: [phone]
 : ----- :  Bitnet: AGUTOWS@WAYNEST1   Internet: [e-mail]
  \=====/
 Have a day.
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Disclaimer:  I think, therefore I am...(I think).

------------------------------

Date:    Tue, 17 Apr 90 16:39:52 -0400
From:    Arthur Gutowski <[e-mail]>
Subject: Hardware protection and the spread of viruses (PC)

With all the discussion of this going around lately, I had a thought.
Doesn't the Amiga use EPROMs for its operating system?  I'm told that
under this type of system, when you order and receive a new version of
the operating system, you flip the write-enable switch on for the
EPROM, install the new operating system into the EPROM, flip the
enable switch off, reboot, and you're off.  Now I know this is an
expensive adventure, but couldn't something like this be applied to
PCs?  Granted, it wouldn't eliminate viruses.  As has been discussed,
as long as there is an application development area and software
trading, the possibility for viruses exist.  But wouldn't this
eliminate an entire class of viruses (namely boot-sector and
partition-table infectors)?  With the entire OS in ROM, there is no
longer a need for executable code in the partition/boot record--it
becomes merely a media/layout descriptor.  This of course all operates
under the assumption that you never receive an infected OS.

Just a thought,
   Art

------------------------------

Date:    Wed, 18 Apr 90 00:11:33 -0400
From:    [e-mail]
Subject: Jerusalem B Virus found at Rutgers U (PC)

This evening I found the Jerusalem B Virus on a friend's machine (read: not
computing center).  I think I got rid of it.

The procedure I used was:

1) boot from clean floppy
2) run scanv39 (the newest I had - getting a newer one now) on it and write
down the filenames infected.
3) delete all infected files and replace from backups after verifying that
the backup is clean
4) re-run scanv39, if not clean repeat 2 and 3.

Is that sufficient?  We know where it came from, so we're contacting that
person to let him know he's infected.

Mark

------------------------------

Date:    18 Apr 90 10:16:00 +0000
From:    [e-mail] (Sverre Holmsen Huseby)
Subject: Detecting "smart" viruses

    About the viruses that desinfects (program-)files when
    they are opened, and reinfects them when they are closed:

    Would it be possible for a checksum-program to detect
    this by recording the time taken to check the file?

    I assume the des-/re-infection takes a couple of timer ticks!


    Sverre H. Huseby   ([e-mail])
    Student   -   University of Oslo, Norway

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 20 Apr 1990    Volume 3 : Issue 78

Today's Topics:

Authoritative/Comprehensive List of Viruses (and Antidotes)?
Yankee doodle, code size =7026 (PC)
Code Size = 7026 (PC)
Virus outbreak in China! (PC)
Dirty Tricks B (PC)
Virus Outbreak in China Reported
Re: Death of a Virus
Re: Virus in Text Files
Why there are no mainframe virii
Re: PCs v. Mainframes
Re: Hardware protection and the spread of viruses (PC)
New viruses (PC)
Disinfecting a Macintosh
Detecting "smart" viruses
RE:virus protection from OS in ROM

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    17 Apr 90 17:23:14 +0000
From:    sppy00![e-mail]
Subject: Authoritative/Comprehensive List of Viruses (and Antidotes)?


I'm looking for a list of all(?) or at least the major viruses which are
circulating about.  If someone could direct me to a publication I'd be most
appreciative.  If you're unaware of this kind of comprehensive list, send
what you do know and I'll summarize.  I was thinking about something like
this:

Virus Name:  <As many names as it's known by, ie.  Jerusalem-B, etc.)
Date First Encountered:
Host: <ie IBM PC,  Apple MacIntosh, UNIX, etc.>
Symptoms:   <ie.  Lock Up System, must reboot, purges files, etc.>
How Distributed:  <ie. Internet,  Floppy Disk,  Source Code, etc.)
Known Antidotes:  <ie. Flushot, procedures to eliminate it, etc.)
Virus Author: <if known>

I'll summarize to the net (naturally!) on everything I get.
My address is --> sppy00![e-mail]
- --
*** ** * | |    OO     CC   L     CC     //
*** ** * | |   O  O   C     L    C      //
*** ** * | |   O  O   C     L    C     //
*** ** * | |    OO     CC   LLL   CC  //    Bringing information to people!


------------------------------

Date:    Wed, 18 Apr 90 12:36:00 -0400
From:    [e-mail]
Subject: Yankee doodle, code size =7026 (PC)

Can anyone provide information on the Yankee Doodle Virus?  Vesselin
(Last Name Forgotten, sorry) gave details on a version in Bulgaria,
but mentioned that there was a separate version in the Western World.
Can anyone confirm or deny this, or provide details??
 Thanks, Mark C. Wallace breah Sullivan

------------------------------

Date:    Wed, 18 Apr 90 12:41:00 -0400
From:    [e-mail]
Subject: Code Size = 7026 (PC)

Jeff Shulman's Virus Detective can produce a report that a given
application has "code size = 7026" Does anyone know what this means???
(I haven't seen the actual warning, so I can't answer for the
capitalization or spacing) Thanks,
          Mark C. Wallace breah Sullivan

------------------------------

Date:    Wed, 18 Apr 90 20:43:00 -0000
From:    [e-mail]
Subject: Virus outbreak in China! (PC)

I thought I would forward this to the group as a matter of interest. It was
taken from JBH Online ( Wed. 18th Apr. )
- - - - - - - - - - - Start of forwarded note - - - - - - - - - -
China:  Computer viruses reported                                       BBC

    The China Daily newspaper reports that a large scale infection of the
country's computers began last Friday, 13 April, when several computer
viruses, including the Jerusalem virus, are believed to have been time
activated.  At least six separate computer viruses have been identified in
Beijing alone.  The BBC is introducing its report of the China Daily
story by referring to the large scale infection as "sabotage."

                   R.Gowans
- -----------------------------------------------------------------------------
JANET:       [e-mail]
Internet:    [e-mail]     Dept Civil Eng,
EARN/BITNET: R.Gowans%MCC.ac.uk@UKACRL              U.M.I.S.T,
UUCP:        ...!ukc!umist!R.Gowans                 Sackville Street,
                                                    Manchester.
FAX:         [044 61  | 061] 200-4016               M60 1QD.

------------------------------

Date:    Wed, 18 Apr 90 16:24:24 -0900
From:    "Big MAC..." <[e-mail]>
Subject: Dirty Tricks B (PC)

I have found Dirty Tricks B on my computer in Various Files.  The only
program that recognizes it is AVS that I FTP'd from MIBSRV.  Can
anyone help me figure out what and HOW to do somehting about it?  SCAN
v60 does not pick it up. Has anyone else had this problem with AVS?

------------------------------

Date:    Thu, 19 Apr 90 08:58:00 -0500
From:    Sanford Sherizen <[e-mail]>
Subject: Virus Outbreak in China Reported

The Wall Street Journal reported today (April 19, 1990) that a virus outbreak
destroyed or damaged data in thousands of computers throughout China last week,
according to the official New China News Agency. I thought that Virus-L people
might be interested in this news.

Sandy

------------------------------

Date:    Wed, 18 Apr 90 17:23:14 +0000
From:    Dave Ihnat <[e-mail]>
Subject: Re: Death of a Virus

[e-mail] (David.M..Chess) writes:

>I disagree with the second, though; unless you label any setting of
>access levels that allows some programs to write to others as
>an "error", viruses can spread even in systems that have reliable
>access controls which are being used properly and without error.
>How many installations can you think of where no program *ever*
>legitimately writes to another?

Yes, that's an error.  I can think of no case whatsoever that *requires*
any program to write to another *program* as a matter of course in the
day-to-day execution of that program.  In all cases, alternative methods
may be employed which permit the executables themselves to remain
inviolate.  Presumably, the software generation cycle (compile/assemble/
link-edit) can, and will, be performed in such a manner as to guarantee
the installation of clean executables before write permission to all is
revoked.  On a regular basis, one of the first things I do on a security
scan of systems is remove write permission from all executables!

This may bring howls of "Not so!", but frankly, they don't belong in this
group.  I will answer any scenario anyone may contrive which seems to
require on-the-fly modification of executable files with alternatives
which, on various operating systems, make use of data files, shared memory
segments, global sections, message queues, etc.  In general, make programs
data-driven, but don't change the code!  But if you wish to indulge in this
gedanken experiment to prove me wrong, please do so with me via E-mail, and
after a period, if necessary, we can summarize to the net.

>I think the reasons that we have seen microcomputer viruses, but no
>large-system viruses are primarily "cultural" (writing viruses hasn't
>become "the thing to do" in the mainframe underground, there simply
>aren't as many mainframe programmers, large installations don't tend
>to exchange software yet, and so on).

Well, maybe.  Seems that the last I heard, there were well over 100,000
Xenix licenses out there; there are certainly at least tens of thousands of
Unix installations of all flavors, running in everything from major research
and industrial installations to my den.  Most universities can tell you that
such ploys as the "login trojan" are common once people become familiar
with Unix.  I think you're right in that sharing of BINARIES isn't common;
but look at the HUGE body of PD and shareware source that proliferates on
USENET, and is archived and freely available to all and sundry via either
ftp or anonymous uucp from a large number of archive sites.  I have to believe
that the same yahoos who think viruses are fun things on single-user OS
machines like PCs and Macs would love to infect Unix and VMS systems, if
they could.  I really do believe that these systems are more difficult to
circumvent, and this has, to some extent, accounted for great disparity
in the number of successful attacks on these systems as compared to the
single-user boxes.  (Of course, when they succeed, they seem to be rather
spectacular, viz. Robert Morris' Internet worm...)

                    Dave Ihnat
                    [e-mail] (preferred return address)
                    [e-mail]

------------------------------

Date:    19 Apr 90 14:34:13 +0000
From:    nvuxr![e-mail] (christopher wood)
Subject: Re: Virus in Text Files

[e-mail] (Alan J Rosenthal) writes:
>cdss![e-mail] (Tom Culliton) writes:
>>How many times has this question been answered?  If you can't execute the
>>file or run it via an interpreter it can't carry a virus.

>A counterexample to this assertion is the wdef viruses on the macs.  They are
>carried in the Desktop file which is a data file describing the layout of the
>windows.

I don't think that WDEF is  counter example; WDEF resources ARE
executed; the WDEF virus is tricky in that it hides an executable
resource in a place that isn't supposed to have executable resources.
You CAN, in rare circumstances, execute the WDEF resource in the desktop
file.

[comments on source-code viruses trimmed]

- --
Chris Wood     Bellcore     ...!bellcore!nvuxr!ccw
                         or nvuxr![e-mail]

------------------------------

Date:    19 Apr 90 18:48:13 +0000
From:    [e-mail] (Iceman)
Subject: Why there are no mainframe virii

I think that the reason that there are "no" mainframe virii is social.
A person does not have to spend ten years learning all of the ins and
outs of a Macintosh to learn how to write a virus.  Any programmer can
go into the nearest Walden's books and walk with Inside Mac, and (in a
few months) s/he can write a virus of the same "quality" as any that
exist today.

Mainframes, with their more complicated operating systems, do not lend
themselves to casual hacking.  If you want to write a Unix virus, you
have to devote some SERIOUS time to learning UNIX.  This dissuades the
casual user from creating UNIX virii.

This is not to say that Mainframe virii do not exist.  I believe that
they do, and are in fact more widespread than people think.  I would
contend that the main use of viral code is to steal information from a
remote computer system, and all the "good" stuff to steal is on
mainframes. People who write mainframe virii generally have a specifc
target in mind, and they write code that gets in, gets the
information, and gets out again undetected.  They are not after
notoriaty in the way that someone who writes an IBM-PC virus which
formats hard disks is.

I tend to see that the PC virus problem, while annoying, is fairly
tame.  As long as people are writing virii which reveal themselves
(whether on purpose or through programming errors), I do not fear.  Of
much greater concern are the high-tech thieves who are not foolish
enough to leave traces.

- -ice

PS:  And if you think data pirating is a cyberpunk fantasy, you
     are mistaken.

- -==============================
reply to:  [e-mail]  Applelink:  ICEMAN
disclaimer: (apples-opinion-p (opinion 'ice)) => nil
- -==============================

------------------------------

Date:    19 Apr 90 21:00:13 +0000
From:    [e-mail] (Ben Cranston)
Subject: Re: PCs v. Mainframes


There have been virus-like objects in mainframe environments.  Some years
ago we got the binary program "animal" for our Unisys 1100.  It played a
game where it tried to guess the animal you were thinking of.  It basically
asked the questions at the branches of a binary tree, when it got to the
end it asked "is your animal a <leaf data>" if you said that it wasn't it
then asked for the name of the animal, then asked for a question that would
distinguish the new animal from the <leaf data> animal, then added a node
at the leaf branching to the old leaf and the new animal.  Outside of a
few "one eyed trouser snakes" it was pretty benign.

Little did we realize that it was ALSO looking for writeable directories
and copying itself into those directories.  :-)

We actually saw it at the end of one of the Unisys distribution tapes, so
we assumed their distribution machine was well infected.

This must have been in the late 1970s or early 1980s (hi Alan!)

- --

"It's all about Power, it's all about Control
 All the rest is lies for the credulous"
- -- Man-in-the-street interview in Romania one week after Ceaucescu execution.


------------------------------

Date:    19 Apr 90 20:59:42 +0000
From:    [e-mail] (Brett Kessler)
Subject: Re: Hardware protection and the spread of viruses (PC)

[e-mail] (Arthur Gutowski) writes:
|>With all the discussion of this going around lately, I had a thought.
|>Doesn't the Amiga use EPROMs for its operating system?  I'm told that
|>under this type of system, when you order and receive a new version of
|>the operating system, you flip the write-enable switch on for the
|>EPROM, install the new operating system into the EPROM, flip the
|>enable switch off, reboot, and you're off.

Actually, it's not that easy.  True, the OS (KickStart) is on a chip,
but upgrading requires the replacement of the chip set.  That's the
_computer's_ operating system.  The DOS, however, is not stored on a
chip, it is stored in the C directory of the bootup disk, plus the
boot sector of the bootup disk has a bit of code to alow the machine
to do it's bootup.

+------///-+------------------| BRETT KESSLER |------------------+-\\\------+
|     ///  |         [e-mail]          |  \\\     |
| \\\///   |              [e-mail]                |   \\\/// |
|  \XX/    |              (PeopleLink)  B.KESSLER                |    \XX/  |
+----------+-----------------------------------------------------+----------+

------------------------------

Date:    Thu, 19 Apr 90 14:57:19 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: New viruses (PC)

                              Three new viruses

Anarkia, a YAJVV (Yet Another Jerusalem Virus Variant) appeared recently.
It is very close to the original version - so close that some anti-virus
programs are not able to notice the difference.  The description I received
follows - perhaps some kind soul would translate it into English.

     Virus Anarkia. Es una modificacion del Viernes 13 bastante
     profunda. Actua igual que el anterior, pero relentiza todas las
     operaciones a partir de la hora, no de los treinta minutos como el
     Viernes 13. En esta variacion del virus el efecto destructivo es el 12
     de octubre. La eleccion de esta fecha no esta clara, quizas porque el
     dia siguiente es un Viernes 13 y para dar el susto un dia antes, o
     quizas porque el dia 12 es el dia de la Hispanidad. Se puede localizar
     facilmente buscando la la cadena "ANARKIA".

I had to remove the accent marks to get this through the mail system.

Another new virus is the Kennedy - It is a simple 333 byte direct-action .COM
infector.  I believe the virus is only known in Denmark.  It activates on three
different dates:

                    November 22nd  (John F.)
                    June 6th       (Robert ? - I thought it was June 5th)
                    November 18th  (don't know why - maybe the oldest brother
                                        died on this date ?)

On this date it will display a message (in Danish) that translates to:

          Kennedy is dead - long live 'The Dead Kennedys'

I have sent a copy of it to McAfee and others, but owners of F-PROT can add
the following line to SIGN.TXT to enable detection of 'Kennedy'.

Kennedy     YEBm-MD52u6FcMV5kMqqmgIAWLuHljjmaYVruOT57v2uf8oL39

                               1971

This is a resident, .COM and .EXE infecting virus from Germany, 1971
bytes long. A search string:

1971        jCJMK52mY2MjNM36gngj+kHO07M4tF48m4cjMT5mgRTMQjBy6v

For detection of some of the other viruses reported recently, the following
lines should be added (or you can just wait for version 1.09, which will be
sent out after next weekend, as soon as it is able to detect and remove the
1720, 1210 and Amoeba viruses)

Durban      fExnSmyMy2jM5j9rJB8XK60zQMH5Ynl6jXa2Mnj53qnh5CAy2C
Pretoria    IVkMAjy5fPWVosyPdWciLq0FKH6j5m8oEyYkN57f76tt4aHv
XA1         g7TTy5-mUM8Hmm5MsY28fH8cR7jfAu1CYYO8Ui5588wvU+mj-C

- --
Fridrik Skulason      University of Iceland  |
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: [e-mail]    Fax: [phone]  |

------------------------------

Date:    Thu, 19 Apr 90 12:25:24 -0400
From:    Peter Jones <[e-mail]>
Subject: Disinfecting a Macintosh

This is probably a dumb question for the veteran MAC users but here
goes. A friend of mine tells me he needs to disinfect his MAC. I can
get hold of the anti-virus programs with no problem. But what bothers
me is how does one prevent the memory from being reinfected from the
hard disk, when the MAC is booted from a known good OS. On the PC, one
boots from a clean DOS; the hard disk isn't accessed until an explicit
command is given. Doesn't the MAC read its hard disk as soon as it
finds it?

I would appreciate very explicit instructions for my friend, as I may be
able to be present at my friend's machine when the disinfection is done.

"Let your flippers do the walking" :-)
Peter Jones                    (514)-987-3542
Internet:Peter Jones <[e-mail]>  ?
Internet:Peter Jones <[e-mail]>  ?
UUCP: ...psuvax1!uqam.bitnet!maint

------------------------------

Date:    Thu, 19 Apr 90 14:16:08 -0400
From:    [e-mail]
Subject: Detecting "smart" viruses

[e-mail] (Sverre Holmsen Huseby) writes:

>About the viruses that desinfects [sic] (program-)files when
>they are opened, and reinfects [sic] them when they are closed:
>
>Would it be possible for a checksum-program to detect
>this by recording the time taken to check the file?
>
>I assume the des-[sic]/re-infection takes a couple of timer ticks!

   The difficulty with this is two-fold: First, it may not actually
take any timer ticks to dis-/re- infect the file, and second, there
are many other events which could alter the total time to check the
file.

   How could it not take any time to dis-/re- infect the file?  Well,
it would take some time, but a timer tick is an awfully long time to
a computer, and for a fast processor to strip the last 4096 bytes off
a file would not take long at all.  For example, on an 80x86 all that
is required is a repeated store byte instruction (which executes very
quickly) to fill the tail of the last meaningful buffer with zeroes,
and then set the file length/buffer length to indicate the appropriate
number of meaningful bytes in the last buffer.  Hardly any time at all.
And no time to reinfect the file, since the disk image remains unchanged.
(I chose 4096 bytes because the 4096 virus is one of these "smart" ones.)

   But more important is the second problem, that of other factors
affecting the time.  Disk fragmentation.  Interrupts occurring and being
handled.  Background processing (in MS-DOS there are TSR's, and there
are other, multitasking OS's too).  Imagine the case where the check is
of a file on a highly fragmented disk, which was not fragmented when the
checksum was generated.  The disk read takes much longer than it did
originally.  And during this time, the user is busily typing the next
command, causing a dozen or so keyboard interrupts.  And the alarm clock
program running in the background is awakened by the timer tick, decides
the alarm time has arrived, and takes over for half a second to produce
a beeping sound.  The total time for the check is quite different, yet
a delaying factor I have pointedly *not* mentioned is the disinfecting of
the file 'on the fly'!  This may or may not have happened, and would be
a minor factor in the overall time.  And there are many, many other
possible factors.  The file could have been copied to a different, slower
medium.  There may be a file handle cache (such as FASTOPEN) or a file
data cache operating, or there may have been one operating when the file
was originally checked.  And so on, and so on....

   For this process to have even a chance of working, everything must be
exactly as it was when the file was originally checked.  According to the
conventional wisdom, we must boot from a secure, non-infected source to
perform the check.  It seems to me that the latter is an easier constraint
to satisfy than the former.

                             Regards,
                             David R. Conrad

+-------------------------------------------------------------------------+
| David R. Conrad           (preferred) [e-mail] |
| /\/\oore Soft\/\/are                  [e-mail]               |
| Disclaimer: No one necessarily shares my views, but anyone is free to.  |
+-------------------------------------------------------------------------+

------------------------------

Date:    20 Apr 90 13:08:00 +0700
From:    "Okay, S J" <[e-mail]>
Subject: RE:virus protection from OS in ROM

>Date:    Tue, 17 Apr 90 16:39:52 -0400
>From:    Arthur Gutowski <[e-mail]>
>Subject: Hardware protection and the spread of viruses (PC)
>
>With all the discussion of this going around lately, I had a thought.
>Doesn't the Amiga use EPROMs for its operating system?  I'm told that
>under this type of system, when you order and receive a new version of
>the operating system, you flip the write-enable switch on for the
>EPROM, install the new operating system into the EPROM, flip the
>enable switch off, reboot, and you're off.

Well, the entire OS is still on media as of AmigaDOS 1.3( the latest
rev),but with 1.4 due out in a week or two, that may change.
Currently though, only Kickstart 1.3 is in ROM. This is also a
regular, non-writeable ROM (I know, I put mine in my HD controller
last summer).  What Kickstart does is provide bootstrap code for the
Amiga to load AmigaDOS. Previously, you had to power on with a
Kickstart diskette in the drive, then boot with AmigaDOS. However, KS
has been in ROM since the A2000 was released in 1987. While this may
seem a little silly, keep in mind that the Amiga can boot as either an
Amiga, Mac, DOS-compatible, or UNIX box,(The Mac and DOS functions
require expansion cards)so you only want to boot to lowest level
needed and then let whoever take it from there.

>expensive adventure, but couldn't something like this be applied to
>PCs?  Granted, it wouldn't eliminate viruses.  As has been discussed,
>as long as there is an application development area and software
>trading, the possibility for viruses exist.
>But wouldn't this
>eliminate an entire class of viruses (namely boot-sector and
>partition-table infectors)?

Actually, until recently, the only viruses we had to contend with were
boot infectors. Then somebody went out and created XENO and BGS, so
now we also have to keep track of file infectors.(Side note here,
wanna see a virus spread *REAL* fast??--try letting it infect your
CRON daemon and see how fast it propagates!!--XENO took out my hard
disk inside an hour ). Fortunately, we do have a pretty good set of
tools to fight the beasties with. (If have an Amiga and don't have
VIRUSX 4.0, get it!!.

 With the entire OS in ROM, there is no
>longer a need for executable code in the partition/boot record--it
>becomes merely a media/layout descriptor.  This of course all operates
>under the assumption that you never receive an infected OS.

True...true...but still a good idea in general. What do you do for
minor bug updates or patches though? --a chip swap would be
frightening to joe_user for every minor upgrade/bug fix though.  There
has been some talk in the past about moving the standard libraries and
handlers into ROM. Maybe in 1.5 :)

>Just a thought,
>   Art
- -------------
Stephen Okay
[e-mail]   Technical Aide, The MITRE Corporation

Claimer:Yes, you're right, these are *MY* opinions

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 23 Apr 1990    Volume 3 : Issue 79

Today's Topics:

Writeable Executables
Re: Disinfecting a Macintosh
Re: Mainframe Viruses
Virus Summary Document
Stoned Found in shrink wrapped GEM/3 (PC)
Length field of ~.EXE header (PC)
Translation of ANARKIA virus description (PC)
Re: Disinfecting a Macintosh
Usenet "virus" {Ed. HOAX - no, that's *not* a UNIX variant...}
Virus listings
Viruses in text files (IBM VM/CMS)
Another virus from Germany (PC)
Twelve-Tricks (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 20 Apr 90 12:19:00 -0400
From:    [e-mail]
Subject: Writeable Executables

The original argument as to wether executables was between Howard Aiken
and John von Neumann.  Dave Chess and Dave Ihnat associate themselvees
with a long tradition when they debate it.  A brief reading of history
tells you that Ihnat/Aiken were right, i.e., correct, but that Chess/von
Neumann carried the day.  For reasons of economics most systems  reserve
the flexibility for executables to be writeable, even by themselves.

Indeed, the only widely used systems that I am aware of that do not
permit this are the IBM S/3X and AS/400.  That they do not is a well
kept secret, even in IBM.  The mechanisms required to enforce this, and
other data-type rules, include hiding all physical storage from the user
and application, as well as a fully qualified program name that includes
the version.

While I have always championed Aiken, and, with Ihnat, am quick to
restrict write permission to executables, I am enough of a realist to
recognize that this strategy is hardly applicable to the problem at hand.
The problem at hand is to stop the geometric growth of existing viruses
in the existing environment.

In the long run, the requirement for trust in programs will drive us
inexorably in the direction of immutable programs and application
specific machines.  As storage and cycles become cheaper, the apparent
penalty for this will vanish beneath the level of notice.  Nonetheless,
writeable executables will never disappear, it won't solve the current
problem anyway, and in the long run, we are all dead.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    Fri, 20 Apr 90 15:31:18 +0000
From:    rutgers!umn-cs.cs.cs.umn.edu![e-mail] (David H. Thornley)
Subject: Re: Disinfecting a Macintosh

[e-mail] (Peter Jones) writes:
>This is probably a dumb question for the veteran MAC users but here
>goes. A friend of mine tells me he needs to disinfect his MAC. I can
>get hold of the anti-virus programs with no problem. But what bothers
>me is how does one prevent the memory from being reinfected from the
>hard disk, when the MAC is booted from a known good OS. On the PC, one
>boots from a clean DOS; the hard disk isn't accessed until an explicit
>command is given. Doesn't the MAC read its hard disk as soon as it
>finds it?
>
>I would appreciate very explicit instructions for my friend, as I may be
>able to be present at my friend's machine when the disinfection is done.

The best way is to boot the Mac from a secure diskette.  This diskette
should have the system and the disinfecting program(s) on it, and should
have the write protect tab in the open position.  Put the diskette in
and turn the Mac on.  (The Mac is set up to boot from a floppy if offered.)
If the computer ejects it, push it back in.  You will then have booted from
a secure system, and can proceed to disinfect the hard drive.  Disinfecting
numerous diskettes can be tedious, of course.

David Thornley

------------------------------

Date:    Fri, 20 Apr 90 13:26:00 -0400
From:    <[e-mail]>
Subject: Re: Mainframe Viruses

About 6 years ago somebody at a California university (I think it was
UCLA) performed an experiment on mainframe viruses.  I remember this
experiment because I incorporated it into a paper I was writing at the
time on national security, including security to government computers.
Unfortunately I don't have the paper any more, but I do remember
(vaguely) where I got the information from.  There was a small write
up of the project in the Boston Globes Science section.  I don't
remember the exact date, but it was between October 1984 and February
1985.

The experiment performed was as follows:

The mainframe (I don't recall what type) was "sealed off", meaning
that any network connections were removed, and all software was backed
up.  A virus was then introduced into an account with normal user
privilages.  The mainframe was then used in its normal way.  By
"normal" I mean that the various programs on the computer were used as
if a group of typical users were doing what they usually do with the
computer.

While the computer was being put through its paces the activity of the
virus was monitored.  I believe that this procedure was performed only
two or three times.  The virus spread throughout the mainframe so
rapidly that system administrators refused to allow it to be run any
more.  I believe that the fasted the virus propogated throughout the
entire computer was within a matter of minutes after it was activated.

Well, the above information is very sketchy.  It's been 5 years since
I've seen it, so I don't remember if it is entirely correct.  But to
anybody who really wants to find out more about mainframe viruses, I
suggest that you try to find this Boston Globe article.  It was very
interesting.

  Bruce Pennypacker
  [e-mail]
  [e-mail]

------------------------------

Date:    Fri, 20 Apr 90 09:37:50 -0700
From:    [e-mail]
Subject: Virus Summary Document

There was a request for information in yesterday's Virus-L for a
summary list of known viruses.  The VSUM9004 document by Patricia
Hoffman is by far the most comprehensive and is available on most
FidoNet nodes, or on HomeBase at 408 988 4004.  It is kept reasonably
up to date and provides information on: Type of Virus; Size; Origin;
Memory Resident Activity; encryption techniques; host types; and a
detailed description of how they work, what activates them and the
visual, disruptive or destructive activation symptoms.  A very useful
document.

Alan Roberts

------------------------------

Date:    Fri, 20 Apr 90 16:16:42 -0400
From:    Jim Dunkin <[e-mail]>
Subject: Stoned Found in shrink wrapped GEM/3 (PC)

Shrink Wrapped Gem/3 Desktop Stoned

Yesterday afternoon I helped a user get rid of the stoned virus that
had infected his machine.  This person believed that he had been
infected from a shrink wrapped copy of "Gem/3 Desktop" that he had
just purchased and tried to install.  I was quite skeptical at first,
but the disks were write protected, the write protect tab was UNDER
the manufacturer's disk label, and the disk label appeared unaltered
in any way.  Still not being a true believer, I went out and bought a
copy of GEM from the same store, and scanned the manufacturer's disks
straight out of the shrink wrap.  Sure eneogh, disk three of a five
disk set contained the stoned virus, according to MacAfee's scan57.
This version of Gem/3 is labelled "Release 3.13 RDK 04/89" with a
serial number of 5153-1921.

A technical representative from Digital Research Inc. in Toronto,
Ontario, Canada indicated to me today that the disks I had were OEM
disks, and that the retail outlet I bought them from, was not
authorized to carry these disks.  He is looking into the matter
further.  The retail outlet I purchased the disks from indicated that
they will pull the disks as soon as they verify for themselves that
there is a problem.

Has anyone else out there stoned GEM disk???

------------------------------

Date:    Fri, 20 Apr 90 12:22:48 -0700
From:    well![e-mail] (Michael Odawa)
Subject: Length field of ~.EXE header (PC)

Recently Fridrik Skulason stated,
> it is not always possible to detect if the program has been damaged beyond
> repair by the [Jerusalem] virus.  This may happen if the information on
> the length of the file which is stored in the header is incorrect.

I believe Fridrik was referring to the information in bytes 02-03 and
04-05 of an ~.EXE file, and if so, I would like to agree with what he
said, but pick one small nit with the way he said it.

The information in these fields is not the length of the file, but the
length of the code image that is to be loaded prior to execution of
the file.  In commercial programs this value is nearly always
"correct," though it may not coincide with the length of the file.

When a linker creates an executable program in which code segments are
overlaid upon each other, only a portion of the entire ~.EXE file need
be loaded prior to execution.  The remaining segments are loaded (and
re-loaded) from either the ~.EXE or an auxiliary (e.g., ~.OVL) file
when called.

Michael Odawa
Software Development Council
[e-mail]

------------------------------

Date:    Fri, 20 Apr 90 15:59:00 -0400
From:    Jim Shanesy <[e-mail]>
Subject: Translation of ANARKIA virus description (PC)

Virus Anarkia.  It's a major variation of the Friday 13th virus.  It
actuates the same as before, but it releases all of its operations on
the hour, not on the half hour like Friday 13th.  In this variation of
the virus the destructive effect is the 12th of October.  The choice
of this date is not clear, perhaps because the following day is a
Friday 13th and to give a scare one day before, or perhaps because the
12th is Hispanic day.  It can be found easily by looking for the
string "ANARKIA".

[Ed. Thanks to everyone who sent in a translation of the Spanish text
that Frisk posted!  I guess that there are indeed a lot of kind souls
out there.  Unfortunately, I'd have to post several (!) digests today
just to send out all the translations that I received.  Instead, I'm
just posting this one (the first that I received).  If anyone has any
serious gripes/corrections in the translation, I'll post them.
Otherwise, the above is the "official" :-) translation.  Thanks again
to all who responded!  It's efforts like yours that make the networks
*worthwhile*!]

------------------------------

Date:    20 Apr 90 13:06:31 +0000
From:    vaxb.acs.unt.edu![e-mail]
Subject: Re: Disinfecting a Macintosh

[e-mail] (Peter Jones) writes:
> This is probably a dumb question for the veteran MAC users but here
> goes. A friend of mine tells me he needs to disinfect his MAC. I can
> get hold of the anti-virus programs with no problem. But what bothers
> me is how does one prevent the memory from being reinfected from the
> hard disk, when the MAC is booted from a known good OS. On the PC, one
> boots from a clean DOS; the hard disk isn't accessed until an explicit
> command is given. Doesn't the MAC read its hard disk as soon as it
> finds it?

If you run Disinfectant, it will remove all (known) viruses, then ask if you
want to reboot (to clear the memory of potential resident virii).

Say 'Yes!'

I haven't seen any problems with reinfection using any of the major
antiviral programs on the Mac... and Disinfectant certainly helped us get
our lab virus problem under control...

Make sure you also check every disk that will be used in the machine...

Or get SAM (Symantec Antivirus for the Macintosh), or Gatekeeper, or one of
the other INIT/DA/CDEV type antivirals for the machine... saves lotsa trouble
later.

>
> I would appreciate very explicit instructions for my friend, as I may be
> able to be present at my friend's machine when the disinfection is done.

If it's Disinfectant, just hit the "About" button and read away... tells you
all you need to know.

Chad Irby                                         "Lookout! it's a code
[e-mail]                                        resource, and it's
\c loaded!"
ac08@untvax

------------------------------

Date:    Fri, 20 Apr 90 20:55:42 +0000
From:    [e-mail] (Peter da Silva)
Subject: Usenet "virus" {Ed. HOAX - no, that's *not* a UNIX variant...}

> I have to believe that the same yahoos who think viruses are fun
> things on single-user OS machines like PCs and Macs would love to
> infect Unix and VMS systems, if they could.

They can.

> I really do believe that these systems are more difficult to
> circumvent, and this has, to some extent, accounted for great disparity
> in the number of successful attacks on these systems as compared to the
> single-user boxes.

I believe you're right, *but* source code has little to do with it.

It's been at least 6 months since I posted this little fable.

                              The Usenet virus: a case history.
                                        A cautionary tale.

                    The Usenet virus was detected when a user discovered that
          a  program  he  had  received  from  the  net  seemed to have two
          versions of malloc included  with  the  source.  One  version  of
          malloc  might  be odd, but people have never tired of reinventing
          the wheel. Two versions were suspicious, particularly since  they
          lead to a name conflict when the program was linked.

                    The first, lmalloc.c,  seemed  to  be  identical  to  the
          malloc  listed  in  Kernighan and Ritchie. The second, bmalloc.c,
          was rather strange, so we concentrated our efforts on it...  this
          time was later found to have been wasted.

                    After a little work during spare moments over the  course
          of  a  week  we  decided  it was actually a clumsy version of the
          buddy system (a  fast  but  space-inefficient  method  of  memory
          allocation).  It  might  make  a good example of how not to write
          readable code in some textbook, but it  wasn't  anything  to  get
          worried about.

                    Back to the  first.  It  made  use  of  a  routine  named
          speedhack()  that  was  called  before  sbrk() the first time the
          malloc() was called. There was a file speedhack.c, but it  didn't
          contain  any  code at all, just a comment saying that it would be
          implemented in a future  version.  After  some  further  digging,
          speedhack  was found at the end of main.c. The name was disguised
          by some clever #defines, so  it  never  showed  up  in  tags  and
          couldn't be found just by grepping the source.

                    This program turned out to be a slow virus. When  it  was
          run,  it  looked  for  a  file 'lmalloc.c'. If it found it, or it
          didn't find Makefile,  it  returned.  From  then  on  malloc  ran
          normally.

                    If it didn't find it, it reconstructed it using a  series
          of  other  routines  with innocuous names tagged on to the end of
          other files. This was  apparently  an  attempt  to  avoid  overly
          increasing the size of any one of the files in the directory.

                    Then it went into Makefile or  makefile  (it  looked  for
          both) and  added lmalloc.o onto the end of the first list of '.o'
          files it found. It then reconstructed each of the extra routines,
          and speedhack itself, using techniques familiar to any reader  of
          the  obfuscated 'C' contest. These were tagged onto the  ends  of
          the  '.c'  files that corresponded to the '.o' files in this same
          list.  The program was now primed to reconstruct the virus.

                    On inspection,  we  discovered  that  about  40%  of  the
          sources   on  our system were infected by the speedhack virus, We
          also found it in one set of shell  archives  that  we'd  received
          but never unpacked or used, which we took as evidence that it had
          spread to a number of other systems.

                    We have no idea how our system was infected.   Given  the
          frequency  with  which  we  make  modifications and updates, it's
          likely that the original speedhacked code is  no  longer  on  the
          system.   We  urge you to inspect your programs for this virus in
          an attempt to track it to its source.  It   almost   slipped   by
          us...  if  the  author  had  actually  put  a  dummy speedhack in
          speedhack.c we would have  merely  taken  lmalloc.o  out  of  the
          Makefile  and  defused *this* copy of the virus without being any
          the wiser.

                    There are other failings in this  program  that  we  have
          thought  of. We have decided not to describe them to avoid giving
          the author of this program ideas we might regret.  Some ways that
          programs like this can be defeated include 'crc' checks of source
          files  and,  of  course,  careful examination of sources received
          from insecure sites.

- -----

Now I have to make a confession. This whole document is a hoax intended
to dramatize the problems involved with viruses and Usenet. I suspect that
most of you were clued to this by the Keywords line. While playing with the
idea and writing this article several things occurred to me:

First of all, this virus is a much more complex program than any of the
viruses that have been spotted on personal computers. I think it has to be,
based on the design goals that a REAL UNIX virus must satisfy. I have not
attempted to actually implement it because of this.

          It must be small, to avoid detection. It must not cause files to
grow without bound.

          It must infect foreign files, otherwise it's not a virus... just a
Trojan Horse (like the bogus ARC and FLAG programs on the PC). Trojan horses
are a dime-a-dozen.

          It must infect source files, since this is the primary software
distribution channel for UNIX. A virus stuck on one machine is a boring
one.

          It must not break the infected program (other than what it might
care to do deliberately).

          It must not be obvious from a simple examination of the source (like,
changing main to Main and having a virus-main call Main).

I believe that given these goals (which are, of course, subject to
debate) a simpler program would be successful in infesting more than a
small fraction of the machines that (say) comp.sources.misc reaches.

There are systems immune to this particular attack, of course. Ones not
running UNIX, so sbrk() doesn't work. Or ones with radically different
versions of malloc(). Ones with no 'c' compiler. They are in the minority,
though.

On the other hand a virus of this type could infest a large proportion
of the net before it was found. The virus I described does not cause any
direct damage, except for using up a relatively small amount of disk
space. A more vicious virus is possible.

Other variations of this virus are obviously possible. For example, it
could be tagged onto any standard 'C' library routine... I chose malloc
merely because source was available and because it's something that people
complain about, so they wouldn't be likely to find an extra copy suspicious.
Another good routine would be perror(), for the same reason. This would have
the additional benefit of making the spread of the infection dependent on
an additional random factor, making it harder to detect the virus.

Do I think something like this is likely? No. Especially not now that
I've written this little piece of science fiction. I'm sure that
eventually someone will try something unlike this, I suspect that their
virus would get caught much sooner than 'speedhack', because I think
that more people look at the source than conventional wisdom would lead
you to believe. But, again, this is just my personal opinion. Debate is
welcomed... that's why I did this in the first place: to inject some
sense into the debate currently raging in comp.sys.amiga.

- --
 _--_|\  `-_-' Peter da Silva. [phone].      <[e-mail]>
/      \  'U`  Have you hugged your wolf today?  <[e-mail]>
\_.--._/
      v        Disclaimer: People have opinions, organisations have policy.

------------------------------

Date:    Sun, 22 Apr 90 20:38:00 -0400
From:    [e-mail]
Subject: Virus listings

I am new in this discussion list, but in many ways old to the whole
subject, since I have been working on various disinfectants since 1988
in Greece (I am also a BBS SysOp in Athens for a BBS which specialises
in virus disinfectants).

I would like to ask a question, and why not, start a discussion about
the moral issue of publishing a virus listing for educational purposes
on a magazine or a book. I have been writing a book about viruses
(unfortunately it is in Greek but I hope to translate it when I finish
it :-) ) and I have been puzzled with this issue. Is it ethically
right to publish code that can create trouble for lots of people, even
if it might be very educational for the non-malicious types of
programmers? If not, is it right to publish disinfectant or vaccine
code? Because even the vaccine code can be easily transformed into a
virus itself, if you only reverse the procedures...

My opinion is that it is inevitable that malicious people will find
the way to write a virus. Therefore, it is OK (in some ways) to
publish code, because it will educate people so that they have the
tools to fight those viruses.

Anxiously waiting for your replies,
Lefteris Kalamaras
Vassar College

- -------------------
Of course, what I
think does not
represent Vassar
anytime!!!
- -------------------

------------------------------

Date:    Sun, 22 Apr 90 20:22:00 -0400
From:    Lynn R Grant <[e-mail]>
Subject: Viruses in text files (IBM VM/CMS)

Viruses certainly ought to be possible under VM, using the Waterloo
Script text formatter.  This formatter has a .sy command that lets you
execute VM/CMS commands while your text file is being formatted.  It
is handy for running EXECs to allocate files your document has to
include text from, but it could easily be put to more sinister uses.


------------------------------

Date:    Mon, 23 Apr 90 08:28:00 -0500
From:    Christoph Fischer <[e-mail]>
Subject: Another virus from Germany (PC)

Over the week end I disassemled a new virus, it was found in Stuttgart,
West-Germany during an anti-virus campaign of a computer magazine.
Here are the facts:
1. It infects COM and EXE type files via INT 21 (4b00)
2. It installs a TSR
3. after its trigger date it will play randomly one of 8 tunes
4. COM type files grow by 1971 bytes EXE will grow 1971 + up to 15 bytes
5. It uses INT 21   INT 08  INT 24
6. Its "music engine" is able to resolve 1/8 notes, doted notes, legato
   non legato, stakato and so on
7. 4of the first 6 tunes are typical German hiking or roving songs dating back
   to a "Back to Nature Movement" in the twenties. The 7th tune ist I think
   garbage. The 8th tune is part of the coding of the virus itself.
   (tune 1: "Jenseits des Tales ..."  tune 2 : "Horch was kommt von drausen
   rein"   tune 3: "Auld lang syne"  tune 4: "Wenn die bunten Fahnen wehen ..."
   tune 5 : "Nobody knows the trouble I've seen" tune 6 : "Hoch auf dem gelben
   wagen"  tune 7 : garbage   tune 8: INT 08 handler)

This is a preliminary analysis, more will follow.
Fridrik Skulason, Dr. Alan Solomon and John McAfee will or have already
included this virus in there scanners.
As a name I discussed with Dr. Alan Solomon "8-tunes".
Sincerely
    Christoph Fischer

*****************************************************************
* Christoph Fischer and Torsten Boerstler and Rainer Stober     *
* Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
* D-7500 Karlsruhe 1, Zirkel 2, Tel.: [phone] or 2067   *
* E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET    *
*****************************************************************

------------------------------

Date:    Mon, 23 Apr 90 08:53:56 -0500
From:    Christoph Fischer <[e-mail]>
Subject: Twelve-Tricks (PC)

Hi,
  two questions connected to twelve tricks recently appeard on VIRUS-L
1.Someone has found "twelve tricks - B" on his disk.
  well there is no such thing as twelve tricks - b the scanner from
  H & B EDV looks for a string, that is expected in an infected partition
  table, in normal files. They didn't read well Dr. Solomon and I published
  an exact report on VALERT-L.  This string can't be found in the "dropper"
  program as well since the "dropper" program uses an encryption method
  to hide its infection code!

2.The gentleman that claims he really has twelve tricks should check
  if he isn't fooled by the same problem as above. If not I sugest
  low-level format / fdisk / high-level format / restore from back-up
  find the twelve tricks dropper and delete that file ( if it is something
  else than a hacked version of the core-test programm please let me know!

We have hundreds of calls of people who run the above mentioned scanner,
it was distributed via a special edition of the CHIP magazine!!!
Sincerely
   Christoph Fischer
*****************************************************************
* Christoph Fischer and Torsten Boerstler and Rainer Stober     *
* Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
* D-7500 Karlsruhe 1, Zirkel 2, Tel.: [phone] or 2067   *
* E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET    *
*****************************************************************

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 24 Apr 1990    Volume 3 : Issue 80

Today's Topics:

VKILL 1.2 (PC)
Re: Mainframe Viruses
WDEF-A on Current-Contents-on-Diskette (Mac)
Exposure in Formatter (IBM VM/CMS)
Current Books about Computer Virus
Update to Memo on Computer Viruses in Commercial Products
Checking for 4096 (PC)
Re: Gatekeeper 1.1.1 & Scores (Mac)
Re: Virus listings
Re: Virus Summary Document
Low Level Format

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 23 Apr 90 13:16:49 +0100
From:    inesc![e-mail] (Antonio Julio Raposo)
Subject: VKILL 1.2 (PC)

          To the readers of the newsgroup comp.virus:

          I sent to Keith Petersen the new version of VKILL and it is now
available at SIMTEL under the name of VKILL12.ZIP. I also sent it to Bill
Davidsen (moderator of comp.binaries.ibm.pc) and I am waiting his answer.
Please do not ask me to send the program until I'm sure it won't be posted,
I will not answer. The main reason for this is that my link with the net
is not very good and I don't want large mails bouncing back and forth.

          Answering those who want to know what I do, I am a working on
microelectronics (design of microchips, investigating new ways of designing
them) and at home I play a lot with my PC developing a system to control
a railway layout. The reason I've done VKILL is just because I hate the guy
who made the virus...

- --
                                        Antonio Julio Raposo
                              ([e-mail] - LISBOA - PORTUGAL)

------------------------------

Date:    Mon, 23 Apr 90 17:16:02 +0000
From:    [e-mail] (Conway Yee)
Subject: Re: Mainframe Viruses

[e-mail] writes:
>About 6 years ago somebody at a California university (I think it was
>UCLA) performed an experiment on mainframe viruses.

I believe the author of the original paper was Fred Cohen.

                                        Conway Yee, N2JWQ

------------------------------

Date:    Mon, 23 Apr 90 09:25:00 -0400
From:    <[e-mail]>
Subject: WDEF-A on Current-Contents-on-Diskette (Mac)

    I just installed Life Sciences Issue 16 of Volume 33 (April 16,
1990) of Current-Contents on Diskette for Apple Macintosh Plus, SE and
II. Upon installation, Gatekeeper Aid popped up and informed me that
it had discovered and removed WDEF-A virus.

    The diskette had just been removed from the (intact) mailing
envelope from the Institute for Scientific Information. Unfortunately,
I had forgotten to move the write-protect tab, so the evidence of
infection is gone. Naturally, I cannot conclude that the disk was
actually infected (as opposed to a glitch in my Gatekeeper Aid), but
if you subscribe to this information service, please use Issue 16 with
caution.

    I have attempted to contact the publishers of this diskette, but
their tech reps haven't yet returned my calls. I'll post again after I
have spoken to them.

- --Mike Tyo,     TYO@MITWCCF            (BITNET)

------------------------------

Date:    Mon, 23 Apr 90 10:24:00 -0400
From:    [e-mail]
Subject: Exposure in Formatter (IBM VM/CMS)

>Viruses certainly ought to be possible under VM, using the Waterloo
>Script text formatter.  This formatter has a .sy command that lets you
>execute VM/CMS commands while your text file is being formatted.  It
>is handy for running EXECs to allocate files your document has to
>include text from, but it could easily be put to more sinister uses.

The ".sy" tag in input to the formatter causes the line to be passed
to the environment to be handled.  In the case noted, the environment
is CMS as a guest under VM.  By default, CMS will pass anything that
it cannot handle to the VM control program (CP).  These are two
different cases of the failure of a program to contain its own
input.

However, the case of the formatter is a much worse case, since
the user-invoker of the formatter often believes that he is dealing
with data and does not recognize the exposure to running commands.
In the case of a command handed to CMS, the user knows that he is
dealing in procedure and probably does not care which layer handles
it.  The formatter case is aggravated by the fact that the formatter
is sometimes invoked by other applications (e.g. PROFS), transparent
to the user.

IBM recognized this exposure years ago.  (From recognition of the
problem to the fix was about a month.  This is a phenomenal response
time for an institution the size of IBM and involved heroic individual
effort.)  Therefore, they placed a user control over this capability.
The IBM shipped default is to require that the ability to pass
commands through the formatter to the environment be specifically
enabled at formatter invocation time.

While this is the "safe" setting of the control, its choice was very
disruptive.  The .sy feature had existed in the formatter for more
than twelve years prior to the installation of the control.
Therefore, the choice of the safe setting as the default meant that on
the day the new control was installed, many procedures that had run
the day before would no longer run.

I can personally testify to the disruption.  On at least two
occasions, I had procedures fail because I had not specifically
enabled the use of .sy.  Even though I had participated in the
decision to install the control and ship with the safe default, it
took me a long time to recognize the problem.

I cannot tell from the comment whether the reference is to a WATERLOO
formatter or a Waterloo implementation of the IBM formatter.  If the
latter, then this may simply be a case of the installation changing
the setting to the "non-disruptive" setting.   If the former, there
may be no control, or the user may simply be seeing an installation
setting.

This is one more case that illustrates the difficulty of
distinguishing program from data.  While safe practice suggests that
they should always be separate, there is great value to the
flexibility of mixing them.  In fact they are often mixed.  Users rely
upon the separation at their peril.  This is a case some few of us know
about; there may be others.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    23 Apr 90 19:56:57 +0000
From:    [e-mail] (Thom Gillespie)
Subject: Current Books about Computer Virus

I write for The Library Journal & Publishers Weekly and I'm working on
a review of current Books about viruses. Please email me your
favorites and I'll repost a listing. If you have just a galley, I'll
look at that also even though few computer book publishers ever claim
to have galleys -- they like to publish them with mistakes and all.
The range of the column will be from popular books Like the Cuckoo's
Egg to source code analysis of the Morris Code, public libraries and
book stores to University Research centers. Thanks.

- --Thom Gillespie

------------------------------

Date:    Mon, 23 Apr 90 07:55:46 -0600
From:    Chris McDonald ASQNC-TWS-RA <[e-mail]>
Subject: Update to Memo on Computer Viruses in Commercial Products

ASQNC-TWS-RA (380-380a)                              November 89
                                                            [Revised Apr 90]

MEMORANDUM FOR RECORD

SUBJECT:  Viral Infections in Commercial/Government Software
DISTRIBUTION: Unlimited

1.  The phenomenon of computer viruses has raised concern  within
government and the private sector as to the use of public domain,
shareware and  freeware  products.   While  it  is  difficult  to
determine the source of "infections" which have occurred over the
last several years, I would propose for the purpose of discussion
that  we  who are involved in automation security services cannot
automatically exclude software  products  as  a  potential  viral
threat  simply  because  the  software  is "commercial" or simply
because software comes from "reputable" sources.  I would propose
as  well that we should be open to the suggestion that there is a
legitimate mission requirement for public domain,  shareware  and
freeware  under  the guidance provided by HQDA and our respective
System Program Managers.  Clearly it is important to have written
policies  and  procedures  to  acquire,  authorize and test "all"
software intended for use on government owned or  leased  systems
regardless of the type of software.

2.   It  seems  desirable  as  well  to  extend  our  concern  to
government developed software. The dependency of our missions and
functions  on  automation  resources  magnifies the potential for
significant disruptions were a government employee or government-
employed contractor employee to initiate a virus infection.

3.   With  that  end  in  mind  I  have  compiled  from  VIRUS-L,
RISKS-FORUM and  other  public  sources  the  following  list  of
"infections"   within   software  packages  identified  with  two
exceptions  as  commercial  and  distributed  all  by   reputable
sources.    The  two  exceptions  include  a  distribution  in  a
commercial   publication,   now   apparently   defunct,   and   a
distribution  by  the  US  Government  Printing Office for the US
Census Bureau.  The list is not complete and is not  intended  to
criticize  any  commercial  firm  or organization.  If anyone has
additional incidents,  I  would  appreciate  receiving  any  such
information so that I may update this list.  Any contributor will
receive the appropriate credit.

4.  MS-DOS INFECTIONS

SOFTWARE                REPORTING LOCATION      DATE     VIRAL INFECTION

a.  Unlock Masterkey    Kennedy Space Center    Oct 89   Vienna
b.  SARGON III          Iceland                 Sep 89   Cascade (1704)
c.  ASYST RTDEMO02.EXE  Fort Belvoir            Aug 89   Jerusalem-B
d.  Desktop Fractal     Various                 Jan 90   Jerusalem (1813)
          Design System


ASQNC-TWS-RA
SUBJECT:  Viral Infections in Commercial/Government Software


e.  Bureau of the       Government Printing     Jan 90   Jerusalem-B
    Census, Elec. County   Office/US Census Bureau
    & City Data Bk., 1988
f.  Northern Computers  Iceland                 Mar 90   Disk Killer
    (PC Manufacturer shipped infected systems.)

5.  MACINTOSH INFECTIONS

    SOFTWARE            REPORTING LOCATION      DATE     VIRAL INFECTION

a.  NoteWriter          Colgate College         Sep 89   Scores and nVIR
b.  Brady Hypercard     Various                 Sep 89   nVIR-A
    1.2.2 (included in the book "Applied HyperTalk")
c.  CMS HardDrive       Various                 Nov 88   Scores
      Utilities, Version 3.4
d.  QLTECH MegaROM      Various                 Oct 88   nVIR
e.  MS Word 4           Various                 Oct 88   nVir
f.  STELLA 2.0          EARN                    Oct 88   nVIR
g.  FreeHand            Various                 Mar 88   MacMag Peace
h.  Grammitik           Various                 Jan 90   WDEF A
i.  Chessmate 2100/     Various                 Apr 90   WDEF
          Cribgin

6.  ATARI INFECTIONS

SOFTWARE            REPORTING LOCATION      DATE     VIRAL INFECTION

WordUp 2.0          Various                 Sep 89   Key

7.  AMIGA INFECTIONS

SOFTWARE            REPORTING LOCATION      DATE     VIRAL INFECTION

Sama Software Inc   Leonard Fetterhoff      1988     Byte Bandit
(Infected disk          Las Cruces, NM
      distributed in "AmigoTimes")

8.   All  of  these  infections  came from products received from
reputable sources and delivered "new." While many of the  reports
are  fragmented  and  incomplete,  there  is  enough substance to
conclude that infection of commercial products has occurred.   It
is  also  possible  to conclude that "certain" vendors have taken
elaborate safeguards to deter the  infection  of  their  products
prior to shipment.  Questions which come to mind include:

a.   Should  we  in  the  Army  require some type of random viral
detection  testing  of   commercial   software   prior   to   its
installation for production tasks?


                                        2

ASQNC-TWS-RA
SUBJECT:  Viral Infections in Commercial/Government Software


b.   Should  software  suppliers  be  asked  to provide technical
information on what policies and procedures they have in place to
address  the potential threat of malicious software modifications
to their product, to include viral detection as a subset  of  the
malicious class?

c.  Should software acquisitions  include  some  type  of  "viral
insurance"  warranty  in  the event a supplier supplies a product
with infected code?

d.  Are policies and procedures in  place  within  Army  software
development  centers  and  activities  to  address  the potential
threat of malicious software modifications?  If so, how do  these
policies and procedures compare with those in the private sector?

9.   This  memorandum  represents  my  own professional views and
should not  be  construed  as  official  USAISC-WSMR  policy.   I
solicit      your      comments      and      suggestions      at
<[e-mail]>  or  at  <cmcdonald@wsmr-simtel20.
army.mil>.




                                        Chris Mc Donald
                                        Information Systems Mgt Specialist

------------------------------

Date:    Mon, 23 Apr 90 21:52:17 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Checking for 4096 (PC)

I just finished disassembling a new version of the 4096 virus and thought
of the following 'interesting' method to check if the virus was active in
memory:

          Set the date to Jan. 1. 2044
          Create a small file (smaller than 4K)
          DIR

If the file is reported as having a length of almost 4 Gigabytes, and the
creation year is AD 100, you are infected with the virus. :-)

- -frisk

------------------------------

Date:    23 Apr 90 22:02:41 +0000
From:    emx.utexas.edu!ut-emx![e-mail] (Chris Johnson)
Subject: Re: Gatekeeper 1.1.1 & Scores (Mac)

Gatekeeper Users and Other Concerned Citizens:

I recently received (through VERY indirect channels) a print of a message
that was posted to VIRUS-L which was an open letter to John Norstad
(author of Disinfectant) about an alleged bug in Gatekeeper 1.1.1,
specifically an inability to stop the Scores virus.

I'd like to tell the Gatekeeper users that may have read that message
that there is no known bug in Gatekeeper which would permit the Scores
virus to successfully spread.  Period.  This is true of *all* versions
of Gatekeeper - and I have never, ever, received a report to the
contrary.

Needless to say, if you have encountered evidence of any such failures
in your use of Gatekeeper, I really do want to hear about them.

I have over the last year-and-a-half repeatedly tested each version of
Gatekeeper against Scores (and all other known viruses) and it has
always proved effective.  (Of course Gatekeeper doesn't stop WDEF,
but that's what Gatekeeper Aid is for.)  Others have repeated those
tests both formally and informally and have always confirmed my
results.

So, I hope the Gatekeeper users who were concerned by this posting
will now sleep secure in their beds once more.

Having said that, I'd like to step up on my soapbox for few moments.

STEPPING ONTO MY SOAPBOX...

I find it highly peculiar that the person who made this posting,
who identified him or herself only as "Zav" in the printout I
received, would be willing to impune the reputation of my product
(Gatekeeper) and, by extension, me in a public letter to the
author of a completely different product.

I mean, what's the point?  Unless John Norstad happened to have
time to forward the message to me, it'd never get to me, so nothing
would ever be done about the alleged problem.  And why make John
play mail-router?  He's busy enough as it is.

The only way such information can be useful is if it is sent to
me, the product's author.  And I'm happy to help... that's why
my email address has always been included in the documentation
for both Gatekeeper and Gatekeeper Aid.

So, I find this kind of thing *extremely* aggravating - it impunes
me and my product, worries users who have enough to worry about
anyway, and DOES ABSOLUTELY NOTHING TO ACTUALLY SOLVE (or verify)
THE PROBLEM.  So, I ask again, what's the point?  Is it just
pulic spleen-venting and product bashing, or was there some
constructive purpose that I wasn't meant to find out about?

OK.  Enough of me and my soapbox.



PROBLEM REPORTS, ETC.

I'd like to, once again, publicly thank everyone who has sent me
their questions and problem reports.

For those of you who've been saving-up your problem reports here's
the addresses (pick only one :-) to send them to:

Internet: [e-mail]
UUCP:               {husc6|uunet}!cs.utexas.edu!ut-emx!chrisj
AppleLink:          [e-mail]@dasnet#

Remember to include the actual version numbers of Gatekeeper and/or
Gatekeeper Aid.

I tend to be a bit swamped with email so don't be surprised if
replies sometimes take a few days, but email is the ONLY way to
get hold of me; I get so much mail everyday that I can't read the news-
groups at all.

By the way, it's not my intention to bypass newsgroups like this; I
would encourage anyone who contacts me with a problem which they feel others
ought to know about to summarize their question and whatever answers
I'm able to provide to this newsgroup.  That way, everyone benefits.
I'd do it myself, but there are only so many hours in the day....  :-(

VERSION CHECK:

The current versions of the Gatekeeper Anti-Virus System's
components are as follows:

          Gatekeeper                    1.1.1
          Gatekeeper Aid                1.0.1

If it seems like it's been a long time since there was a new Gatekeeper
release, don't dispair:  development of new versions has been underway
for many months and will eventually result in several new and worthwhile
releases.

Thanks for the time and the bandwidth,
- ----Chris (Johnson)
- ----Author of Gatekeeper
- [e-mail]

------------------------------

Date:    Mon, 23 Apr 90 20:03:03 -0400
From:    Yary Richard Phillip Hluchan <[e-mail]>
Subject: Re: Virus listings

I personally own books on how to make explosives, how to pick locks,
etc. not because I want to blow up an embassy but because I'm curious to
how it's done.  Real theives learn how to pick locks on the street,
terrorists can read about chemisty in a library.

If you publish virus source listings, people will try to censor you and
your book and blame it for subsequent viruses.  The truth is, the
information is already spreading among underground bb's the world over.
All a legit book will do is tell non-involved folks what's going on.

Anyway, information isn't dangerous, just people who misuse it.

------------------------------

Date:    Mon, 23 Apr 90 20:06:37 -0400
From:    Yary Richard Phillip Hluchan <[e-mail]>
Subject: Re: Virus Summary Document

]There was a request for information in yesterday's Virus-L for a
]summary list of known viruses.  The VSUM9004 document by Patricia
]Hoffman is by far the most comprehensive and is available on most
]FidoNet nodes, or on HomeBase at 408 988 4004.  It is kept reasonably
]up to date and provides information on: Type of Virus; Size; Origin; ....

Is that list (VSUM9004) available from an anonymous ftp anywhere? Sounds
useful.

[Ed. I put the file on cert.sei.cmu.edu in pub/virus-l/docs yesterday,
for anonymous FTP access.  Those without anonymous FTP can get the
file from the HomeBase BBS, [phone].]

------------------------------

Date:    Tue, 24 Apr 90 09:56:55 -0000
From:    [e-mail]
Subject: Low Level Format

          Several people on VIRUS-L have asked me to summarise the replies I ha
\cd
to my question on low level formatting and whether it is necessary to carry
out a low level format of the hard disk as part of the virus recovery process.
Here is what I think the replies said (with a general acknowledgement to the
authors of the original replies and apologies if I have misinterpreted the
information they gave me!)

1. Difference between the DOS FORMAT command and a low level format:
The DOS FORMAT command when applied to a hard disk does not perform a physical
format of the disk only a logical format. The hard disk is given a new boot
sector, a clean File Allocation Table (FAT) and an empty root directory. Thus
the file system is emptied but the file *data* remains on the disk until
overwritten by new files. When the DOS FORMAT is applied to a floppy diskette
a low level physical format is performed on the diskette as well as a logical
format.

2. How to carry out a low level format:
This is usually done at the factory or the dealer when the hard drive is mated
with a controller card. You can perform a low level format with the diagnostic
disk supplied with your PC (usually with a program called HSECT) or by executin
g
that is stored in the BIOS on the controller card (using DEBUG.) The process is
not documented and not for the squeamish! The exact instructions vary from driv
e
to drive. The low level format actually physically formats the disk, dividing
it into tracks and sectors and putting special labelling information in front
of each sector to identify it. All data on the disk is destroyed.
After you do a low level format you must Fdisk the hard disk to create a DOS
partition and then you must do a logical format with FORMAT using the /s
option to make the disk bootable.

3. Is it necessary?
Low level formatting is almost never necessary. Most viruses corrupt .COM and
.EXE files which can be restored using a disinfection program or deleted and
restored from backup copies. The only viruses which cause problems are:
Taiwan which sometimes destroys the infected program instead of properly
infecting it.
Jerusalem which occasionally corrupts a file while infecting.

Vienna and Lisbon variant which destroys 1 in 8 of the files it infects.

405 and other overwriting viruses.

With boot sectors formatting is not required. The original boot sector can be
recovered easily with the exception of the Swap (Fallboot) virus.

When cleaning up after the Dark Avenger virus it is strongly advised
to format the disk using the normal FORMAT command and restore all
programs and data files form backups. Dark Avenger may have garbled
some sectors on the disk and possibly destroyed data or program files.

There is one virus that requires low level format - when the Disk Killer virus
activates it starts encrypting the hard disk including the partition table.
DOS format can't handle this and you need to run FDISK first and possibly a
low level formatting tool.

Hope this is useful info and sorry for the length of the message.

Rgds,

Iain Noble (Teesside Poly Library, UK)
- -----------------------------------------------------------------------------
Iain Noble                                   |
[e-mail]                           |  Post:  Main Site Library,
JANET: [e-mail]                    |         Teesside Polytechnic,
EARN/BITNET: LBA002%pa.tp.ac.uk@UKACRL       |         Middlesbrough,
INTERNET: [e-mail] |         Cleveland, UK, TS1 3BA
UUCP: [e-mail]            |  Phone: [phone] x 4371
- -----------------------------------------------------------------------------

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 25 Apr 1990    Volume 3 : Issue 81

Today's Topics:

Re: Writeable Executables ( in AS/400, /38 )
Re: Writeable Executables
Re: Exposure in Formatter (VM/CMS)
re: PCs v. Mainframes
Virus information sought
Stoned Virus and Clean-Up (PC)
New Programs from McAfee (PC)
Re: Writeable Executables
WDEF-A on Current-Contents-on-Diskette (Mac)
Re: Exposure in Formatter (IBM VM/CMS)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    24 Apr 90 14:26:44 +0000
From:    Reinhard Kirchner <[e-mail]>
Subject: Re: Writeable Executables ( in AS/400, /38 )

[e-mail] writes:
> The original argument as to wether executables was between Howard Aiken
> Indeed, the only widely used systems that I am aware of that do not
> permit this are the IBM S/3X and AS/400.  That they do not is a well
> kept secret, even in IBM.  The mechanisms required to enforce this, and
> other data-type rules, include hiding all physical storage from the user
> and application, as well as a fully qualified program name that includes
> the version.
>
> While I have always championed Aiken, and, with Ihnat, am quick to

The secret is not so big if there is a little understanding of the
mechanisms in the AS/400-:)

At first, there are no files on a AS/400, but merely objects in a very
large storage ( addresslength is 48 bit, expandable to 64 ). To gain
access to an object one needs a 'capability' with sufficient rights
for this object.

Executable objects are not accessible at all, only executable. I don't
know how this is made exactly, but perhaps the compiler throws the
write-capability away after compiling -;)

The AS/400 executables are also not using a known instruction set, but
an internal 'micro'-instruction set which is not known and which may
change from modell to modell. Compilers generate an immediate code,
which is published ( till now only for the /38 ), but extremely hard
to understand ( I tried and failed -:( ), and this is then by a
machine- instruction translated to the executable object. There are
megabytes of microcode in a AS/400. In its protection mechanisms the
AS/400 is shurely the most advanced machine ever sold, perhaps even
built.

The AS/400 seems to be an enhanced System /38 ( intermediate binaries
of the /38 can be used on the AS/400 ), and, as far as I know, the /38
was an outcome of the 'Future System', which should be the successor
of the /370, but was never announced because people would have bought
Amdahls /370 insteed.

The /36 is a outdated 16-Bit machine and has nothing in common with the
/38 ( except '/3' ) ( oh, both use the same terminals etc ).

R. Kirchner
University of Kaiserslautern
Dept. of Computer Science

[e-mail]

------------------------------

Date:    Mon, 23 Apr 90 21:14:00 -0400
From:    [e-mail]
Subject: Re: Writeable Executables

>But nowhere do you mention who was on what side.  Could you do an
>explainitory post?

Sorry.  I had not intended to be cryptic.  I will be happy to elaborate.

Howard Aiken was the director of MIT's computing laboratory, which now
bears his name.  John von Neumann was a Princeton physicist, for whom
the von Neumann architecture is named.  Von Neumann's most important
contribution to computing was the observation that if one stored
procedures and data in the same memory, then one could do arithmetic
on the program.  One would also be able to put off the allocation of
storage across the two uses until the very last moment.  Given the
incredible cost of storage in the forties, that was seen by most as a
truly brilliant concept.

This concept, called stored program computing, was probably the single
most important idea in the evolution of the modern computer.  It was
the idea, that more than any other, distinguished the computers of the
fiftys from the calculating machines of the fortys.  It gave the
computer a significant economic boost.  It also sewed the seeds for
the modern virus.

Aiken resisted the idea, partly because of the potential for the
program to be corrupted, but also likely because he failed to think of
it himself.  Aiken's machines, like most others of his day, put data
in one kind of storage and procedure in another.  For example, data
might be in "counters" or vacuum tube rings, where it could be easily
modified, and procedure in punched paper or a control panel, on the
assumption that it did not need to be modified.  It seems strange now,
but this organization persisted into the early sixties.  For example,
the IBM 305 RAMAC, one of the first two computers to employ disk
storage, used the disk exclusively for data, and not for programs.

The idea of storage allocated to program and more or less resistant to
modification has never really died out.  It persists in ROM BIOS, for
example.  The Toshiba 1000 SE notebook-size and the ATARI and Poqet
pocket-book-sized computers all ship their operating system in ROM.
In the case of the Toshiba, the operating system is MS-DOS.  Even the
IBM PC1 had the BASIC interpreter in ROM.  Of course, in these
implementations this is done, in part, to compensate for the absence
of disk drives, or to use cheap ROM to add value, rather than to make
the programs resistant to change, but it is a value nonetheless.

Note the speculation and hoaxes regarding using such specialized
stores as places to store viruses.

Hope this clarifies a little.  It is hard for me to always remember
that you were not all there.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    Tue, 24 Apr 90 12:36:00 -0400
From:    Lynn R Grant <[e-mail]>
Subject: Re: Exposure in Formatter (VM/CMS)

To clarify my report of the .sy exposure in Waterloo Script...
Waterloo Script is a different product from IBM Script (or DCF or
whatever).  It comes from University of Waterloo, through their
marketing arm, which I believe is called WATCOM.  Waterloo Script
takes almost the same input tags as IBM Script; they are close enough
that if you are comfortable with one you will be comfortable with the
other, but just enough different that a file that works with one
probably won't quite work on the other.  I couldn't find anything in
the Waterloo doc about an option to suppress .sy tags, so I looked in
the source.  Sure enough, there is a SYON/SYOFF execution time parm.
I has the less safe but also less disruptive default of SYON.

    Lynn Grant
    Consultant
    Computer Associates International, Inc.
    Chicago, Illinois
 DOCKMASTER.NCSC.MIL)

------------------------------

Date:    23 Apr 90 00:00:00 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: re: PCs v. Mainframes

Interesting discussion whilst I was on vacation!   I'll reply to
various notes at once (apologies if I get longwinded...).

Bill Murray is certainly correct that I may not have listed all, or
even the most important, cultural factors that have led to there being
so many more viruses for small computers than for large ones.  My main
point is that cultural factors rather than technical ones (patterns of
usage rather than the existence of security features, for example) are
the correct explanation.  I'd be very interested in any hard evidence
that anyone has as to the relative importance of machine sharing,
software sharing, and media sharing in the spread of viruses; lacking
that, it's mainly just personal intuition.

Arthur Gutowski says that systems programming is simply harder
on mainframes than it is on micros (quite possibly true, although
I think the fact that the knowledge is less widespread is more
important than the possible fact that it's harder), and that
security systems would get in the way.   I rather disagree with
the latter, of course: viruses don't have to get around security
systems to spread; they spread by writing to objects that they
are authorized to write to.   (More details below.)

Dave Ihnat says that any time one program has write access to
another, there's an error in the way the system is set up:

> Yes, that's an error.  I can think of no case whatsoever that *requires*
> any program to write to another *program* as a matter of course in the
> day-to-day execution of that program.  In all cases, alternative methods
> may be employed which permit the executables themselves to remain
> inviolate.

and challenges everyone to contribute counterexample scenarios.  Here
are a few candidates:

   - A user or system administrator installs a new program
   - A user or system administrator installs a new version of an
     existing program
   - A backup program makes a backup copy of an executable file
   - A linker produces a new version of an executable from source
   - A program is written to magnetic media for transport to
     another computer
   - A program is sent to another computer via a communications link
   - A copy program is used to copy or move a program file
   - A text-editor is used to make changes to source code in an
     interpreted language (or any other language, for that matter)

and so on.  Every time any one of these events happens, there's a
chance for a virus to spread, unless the system is first brought into
a state in which every piece of code along the relevant execution
paths is "trusted".  Getting the system into a trusted state is (to
say the least) non-trivial in every real live system that I know of!
I agree that programs very rarely, or even never, have to be
self-altering; but many programs by their very nature have to be
other-altering (how would you like a copy utility that didn't work on
anything but pure text files (and even that wouldn't do it)?).

I'm very interested in "Iceman"s comments about targetted mainframe
viruses.  Do you have any concrete information that you can share with
us, or is your statement based on confidential information, or
personal intuition?

As Bruce, Peter, and Ben (I think it was!) all pointed out, there have
in fact been viruses and virus-like things in mainframe systems.  Fred
Cohen's "Computer Viruses; Theory and Experiments" describes a number
of experiments conducted on real live multiuser systems that showed
that simple-to-write viruses, not exploiting any bugs in the security
systems, could spread widely and rapidly on a system.  Now of course
it's possible to say that that just shows that there were errors in
how the security was set up, but I don't think a definition of "error"
that covers 99% of the systems in actual use in the real world is very
useful; if virus-protection on a mainframe requires security
disciplines that no one in fact uses, and that no one would find easy
enough to implement to be cost-effective, that's little or no comfort.
If we can define a security discipline that is both useable and very
effective against viruses, that'd be very nice!  But I haven't seen
one yet...

DC

------------------------------

Date:    Tue, 24 Apr 90 09:42:55 +0700
From:    <[e-mail]>
Subject: Virus information sought

Hello Virus Experts!

We (a group of people here at the University of Duesseldorf) try to
cope with several viral infections on our computers (PC). We had "some
problems" with several viruses on our business machines and also on
our private ones.  Since this was the first time our systems were
infected, we were really surprised and lost a lot of data. You can't
imagine how fast the several viruses spread to all uninfected systems
and destroyed everything they could get even without any network ...
(It's every time the same story ...)

Now we try to get our own experiences with the several viruses and
how to cope with the infections. We have established an isolated
system where we are doing our work. So we are looking for an overwiev
of all known viruses (i.e. how they react and get visible, what
damage is resulting, which interrupt vectors are hooked, are there
programs which can destroy some viruses, etc...).  I think it is
better to be informed about possible viral infections on the systems
and to have experience in destroying viruses than waiting for the
next virus and having no tools against it.

Many thanks to Prof. Klaus Brunnstein at the University of Hamburg (W.
Germany) from where I got a first overview about the most common
viruses.  Never the less, if we can get more information, we are very
happy.

On our systems at the University we solved the problem of getting
infected on our PC's (for the student users) by a little trick: We put
two hard disks (really two physical, not logical drives) in the
machines and changed the keyboard key lock in that way that it now
controls the writing electricity cables of one hard disk so that no
writing operation can be done on this (bootable) hard disk.  On the
other hard disk you can do your writing and reading operations for
data as usual. (The other advantage of this system is that our
software (campus licenses ...) now can't be modified by any unallowed
person).

There's one last notice: We are trying to get as much information as
possible about the several viruses (for PC's only, not Amigas or
other). You may send us your information (any type) via e-mail
directly to [e-mail] or to the adress below or to the
list. But as everybody will understand,
 --- WE DO NOT SEND NOR EXCHANGE ANY VIRUSES ---
because we want to solve problems caused by viral infections and not
to help spreading those viruses (and resulting problems) around!
Please accept it. Thanks.

Well, that's enough (for the moment). Any comments or suggestions can
be sent to this list or directly by e-mail to our address
([e-mail]).

     Thanks to everybody who wants to help us.
                               Yours, Stephan Joest.

The address is:
   Stephan Joest, Universitaet Duesseldorf, Universitaetsstr.1/19312,
   D - 4000 Duesseldorf 1, West Germany

 for BITNET users:  [e-mail]

------------------------------

Date:    Tue, 24 Apr 90 16:11:10 -0700
From:    [e-mail]
Subject: Stoned Virus and Clean-Up (PC)

          The Stoned virus is one of the more troublesome viruses to
remove from a hard disk because it takes up residence in the hard
disk's partition table.  Even a DOS Format won't get rid of it.
Clean-Up successfully removes this virus, but John McAfee has posted
the following warning about its use on Homebase:

          "If the Stoned virus has infected any of the older hard disks
that require a software device driver in order to access them, ala'
Priam, then do not use the Clean-Up program without first backing up
any data on the disk that you wouldn't be comfortable losing.
Clean-Up will certainly kill the virus on such drives, but it may also
kill the partition table.  This is not good.  And there is no easy
fix.  It's amazing how many Priam drives are still spinning out there
after 8 years of heavy use.  If you're unsure whether your disk uses a
non-standard device driver, then please contact us at 408 988 3832
prior to using Clean-Up."

So far fewer than one system in a thousand has this problem, but it's
one system in a thousand too many.

Alan

------------------------------

Date:    Tue, 24 Apr 90 15:39:16 -0700
From:    [e-mail]
Subject: New Programs from McAfee (PC)

The following is a forward from John McAfee:
==================================================================

          We have made two changes to the SCAN shareware product line
that I hope will improve the virus protection capabilities and
respond to the numerous change requests we have received from the
user base.
          The first is a re-design of SCANRES and (please bear with us)
a name change from SCANRES to VSHIELD.  The new VSHIELD contains
all of the functionality of SCANRES, plus it is now able to prevent
all known boot sector and partition table infections as well as all
known file infections.  This capability was added because of the
increasing prevalence of boot sector viruses such as Stoned, Ping
Pong, etc.  SCANRES was able to identify such infections
immediately after they occurred, but could not prevent them.
VSHIELD prevents such infections from occurring, providing of
course that VSHIELD is in memory.  Thus, soft re-boots (Ctrl-Alt-
Del's) will no longer transfer a boot virus infection providing
VSHIELD has been loaded.  If the system is powered down before re-
booting from a floppy, then VSHIELD is no longer running and the
infection can occur.  In this case, VSHIELD, like SCANRES, will
flag the infection immediately upon the next boot-up from the hard
disk.  Other changes include error level settings identical to
SCAN,  a de-install function, and improved reporting when an
infected file or diskette is blocked from entering the system.
These changes have been requested by users for some time, and we
regret the delay in implementing them.  Beta testing by a few dozen
fearless people has uncovered no false alarms or other system
hindrances from VSHIELD.
          The second change is an added new program designed
specifically for software manufacturers, developers and
distributors to protect their software products prior to
distribution.  The program -- FSHIELD -- attaches a small module
to existing executable code that will monitor for infection similar
to innoculation programs, but in addition it automatically removes
the virus and repairs the host program if the host program becomes
infected.  Files shielded in this fashion cannot contract or pass
an infection and cannot be damaged by a virus attachment.  The
shield module detects and removes known and unknown viruses,
including "stealth"-type viruses, and adds approximately 2K to the
size of the host program.
          Both of these new programs are ShareWare.  VSHIELD is
currently available for download on HomeBase - 408 988 4004.
FSHIELD will be available for download May 1.

John McAfee

------------------------------

Date:    Tue, 24 Apr 90 13:45:20 +0000
From:    [e-mail] (Peter da Silva)
Subject: Re: Writeable Executables

What's an executable?

Oh, something that the computer executes. You don't want programs to be able
to write into executable files. Sorry, it'll never happen. I'm sure, in
fact, that given a little time I could infect your AS400 (or whatever), at
least with a REXX script (or equivalent).

Yep. Command scripts. A fertile breeding ground for viruses. And how about
Postscript files? You want to turn off write permission on all your fonts?
- --
 _--_|\  `-_-' Peter da Silva. [phone].      <[e-mail]>
/      \  'U`  Have you hugged your wolf today?  <[e-mail]>
\_.--._/
      v        Disclaimer: People have opinions, organisations have policy.

------------------------------

Date:    Tue, 24 Apr 90 20:21:00 -0400
From:    <[e-mail]>
Subject: WDEF-A on Current-Contents-on-Diskette (Mac)

Relative to the reported infection of Life Sciences Issue 16 of Volume 33
(April 16, 1990), I spoke yesterday with a technical representative of the
Institute for Scientific Information (ISI). They were profusely apologetic,
and indicated that they found out that yes, indeed, this issue was infected
with WDEF-A. They said that they would soon be notifying all recipients of
this issue and sending them a replacement disk as well as Disinfectant 1.6
to decontaminate infected systems. However, as of today (April 24), I have
not yet received these materials, nor have I received any notification at
all from ISI that my Mac may be infected. I did receive issue 17 today, and
it is clean (per Gatekeeper and Disinfectant 1.7).

So, if you subscribe to CC-on-diskette for the Macintosh, please be advised
that Issue 16 may be infected with WDEF-A.

Mike Tyo             TYO@MITWCCF   (BITNET)

------------------------------

Date:    Tue, 24 Apr 90 22:27:02 -0400
From:    Doug Sewell <[e-mail]>
Subject: Re: Exposure in Formatter (IBM VM/CMS)

[e-mail] says:

>I cannot tell from the comment whether the reference is to a WATERLOO
>formatter or a Waterloo implementation of the IBM formatter.  If the
>latter, then this may simply be a case of the installation changing
>the setting to the "non-disruptive" setting.   If the former, there
>may be no control, or the user may simply be seeing an installation
>setting.

We've had Waterloo script (which has its roots in RUNOFF, and is
nearly source-compatible with IBM's) for years, and have reinstalled
it at least four times (upgrades).  To my recollection, there is no
way to turn this 'feature' off at install time, and the short test I
just ran (a 1-line .sy cp m * hello) did what I expected - sent me a
message, so if it is settable, the default is 'ON' ):

I can just see scripting a document for PD VM software with a '.sy cp
shutdown' or '.sy erase * * a1' imbedded in it, and then explaining
that I was only printing documentation.  Is nothing sacred anymore ?

Seriously, though, I have a new release tape waiting to be installed.
I'll check and see whether this option is suppressable.  If so, I'll
turn it off in 'profile script', and if not I'll be calling Watcom.
Waterloo Script is shipped with source (surprising, since Watcom's OCO
products are date and cpuid protected), so I could fix it there, but I
shouldn't have to.

Doug Sewell, Tech Support, Computer Center,
Youngstown State University, Youngstown,  OH 44555
E-mail: [e-mail], [e-mail]
>> Don't test for an error condition that you don't know how to handle.

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest   Friday, 27 Apr 1990    Volume 3 : Issue 82

Today's Topics:

Re: WDEF-A on Current-Contents-on-Diskette (Mac)
Write-access to Executables
New Virus? (PC)
Re: Exposure in Formatter (was IBM VM/CMS, now UNIX)
*really* fail-safe virus protection
Anti-virus cleaning programs that are shareware (PC)
Kennedy Virus
Writable Executables
Writable Executables
Possible virus? (Mac)
CMOS attackers (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    25 Apr 90 13:25:56 +0000
From:    phillips <[e-mail]>
Subject: Re: WDEF-A on Current-Contents-on-Diskette (Mac)

[e-mail] writes:

>     I just installed Life Sciences Issue 16 of Volume 33 (April 16,
> 1990) of Current-Contents on Diskette for Apple Macintosh Plus, SE and
> II. Upon installation, Gatekeeper Aid popped up and informed me that
> it had discovered and removed WDEF-A virus.
>
>     The diskette had just been removed from the (intact) mailing
> envelope from the Institute for Scientific Information. Unfortunately,
> I had forgotten to move the write-protect tab, so the evidence of
> infection is gone. Naturally, I cannot conclude that the disk was
> actually infected (as opposed to a glitch in my Gatekeeper Aid), but
> if you subscribe to this information service, please use Issue 16 with
> caution.
>
[stuff deleted]
>
> - --Mike Tyo,     TYO@MITWCCF            (BITNET)

ISI just re-sent Issue 16 with Issue 17 this week, and threw in
Disinfectant 1.6.  They enclosed a letter warning users not to "load"
the infected issue 16, explaining generally what WDEF is, and
expressing their regrets.

In the letter, ISI claims that they are 'making every effort to detect
and prevent the spread of computer viruses.'  Over the phone, tech
support at ISI claimed that they availed themselves of the 'latest
virus detection software.'  Obviously, neither of those claims are
true, and the fact that they are using an older version of
Disinfectant makes it clear that they are not aggressively searching
out tools to fight viruses.  Further, the letter makes the mistake of
warning users not to 'load' the issue (a process which involves
decompressing the files and placing them in a folder) instead of
warning users not to place the diskette in the drive at all, and
leaves the impression that if you didn't go through the issue loading
process, you would not be infected.  So either they don't really know
what they are talking about, or they don't care to make it clear to
the people they have sent this virus to.

Subscribers to the Current Contents on Diskette [Mac] service should
use extreme caution when using their software.

- --Mark Phillips ([e-mail])

------------------------------

Date:    Wed, 25 Apr 90 14:38:13 -0000
From:    "Pete Lucas" <[e-mail]>
Subject: Write-access to Executables

I followed the discussion about writable executables with interest: Am
i missing something? It seems to me that *no* executables should be
'writable' by *any* program under normal circumstances.!.!  Consider a
simple program development cycle:

          Program source (readable and writable by its owner...)
              !
              !
          Compiler (a program with no write permission on itself)
              !
              !
          Object file (with no write permission...)
              !
Libraries     !      (Libraries have no write-access either...)
     !        !
     !        !
     -------Linker    (a program with no write permission on itself)
              !
              !
           Executable (an executable with no write access).

Now when you make a change to the source, you recompile and re-link,
and if you know what you are doing, *ERASE AND RECREATE* the executable
module. It will probably be a different length in any case, so the
file-system may have to do this to fit it in.
If the resultant executable has no write access (but, for your sake i
hope it has execute permission!) then you can be reasonably sure that
if the source code is kosher, and the object/libraries are clean, then
the resultant executable can be OK too.
(There is always the danger that someone could, of course, write a
bootleg, trojan-library  or compiler that generated executables 'not
quite' like what the source code intended.....)
The risks arise when people have 'write-enabled' executables (so they
can use SUPERZAP or some similar patching tool to hack the executable,
and they leave the thing 'write enabled' afterwards.
Viruses can then patch their way in later...
OK i admit that such tools that patch the executable (and also things
like UPDATE/MAKE mechanisms for source maintenance) can be damned useful
at times, but as in all these things, a powerful tool can make a big
mess very quickly! I hope that those of you involved in SOURCE CODE
maintenance realise the risks! I could easily forsee a trojan 'make' file
that added an extra few routines for its own nefarious purposes, and
patched in wormholes for future subsequent malicious usages.
Likewise for text-formatter input.
(the .sy command also exists in IBM's SCRIPT, and, yes, it works!)

   Pete Lucas         [e-mail]       0793-411613

------------------------------

Date:    Wed, 25 Apr 90 11:40:00 -0400
From:    Don Kazem <[e-mail]>
Subject: New Virus? (PC)

I received a call today from one of the local chain food stores about
what could be a new virus. Since they have no connection to the
network, I offered to post this.

A user was running Lotus (by invoking 123.exe), and after a file
retrieve, the virus was triggered. The following message was
displayed: (The spelling errors are the same as they appeared).


IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM;
:                                                                      :
:          CONGRADULATIONS -- YOU HAVE JUST WON THE RAMDOM SELECTION   :
:                                                                      :
:                AS A SPECIAL PRIZE YOU WILL RECEIVE ONE               :
:                          IMMMMMMM;                                   :
:                          : HARD  :                                   :
:                          :       :                                   :
:                          : DISK  :                                   :
:                          :       :                                   :
:                          : FORMAT:                                   :
:                          HMMMMMMM<                                   :
:                        STARTING NOW                                  :
:                                                                      :
:                  BREAK WILL NIT HELP!                                :
HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<

Formatting drive: C
Cylinder:  733
Head:    6
Sector:   25
Status:    0
WARNING: TURNING OFF COMPUTER MAY DAMAGE HEADS!


After a while, the words "JUST KIDDING" appeared, and everything went
back to normal. Although, it appeared as though there was no damage,
they ran Wipedisk, and installed everything from the original disks.

They ran SCAN61 both before and after reinstalling the software, and
SCAN did not find anything.

The have a backup of the hard disk, before they ran Wipedisk, and are
willing to forward copies of their executables to researchers (lawyers
permitting).

Has anyone heard of this?

Don Kazem
National Academy of Sciences
[e-mail]

DISCLAIMER: I am merely acting as a messenger, I have not seen the
virus, nor have any connection with the infected party.

------------------------------

Date:    25 Apr 90 17:11:52 +0000
From:    [e-mail] (Ralph A. Shaw)
Subject: Re: Exposure in Formatter (was IBM VM/CMS, now UNIX)

[e-mail] writes:
>>Viruses certainly ought to be possible under VM, using the Waterloo
>>Script text formatter.  This formatter has a .sy command that lets you
>>execute VM/CMS commands while your text file is being formatted.  It
>>is handy for running EXECs to allocate files your document has to
>>include text from, but it could easily be put to more sinister uses.

Now that you mention it, there is a similar function in the UNIX text
formatter nroff, whereby programs may be specified to be executed via
the ".pi" request.  This has existed back as far as '78, although I
have never seen any uses of it, malicious or otherwise.  It would be a
totally unexpected source of mischief, but quite functional.

------------------------------

Date:    Wed, 25 Apr 90 15:59:00 -0400
From:    [e-mail] (*Hobbit*)
Subject: *really* fail-safe virus protection

Finally someone else comes up with the *correct* solution!

Stephan Joest and friends
   ... changed the keyboard key lock in that way that it now
   controls the writing electricity cables of one hard disk so that no
   writing operation can be done on this (bootable) hard disk.

I.e. the write gate.  This is an active-low line from the controller to
the hard drive which when disabled "floats" high.  Simply opening this
line prevents any writes to the hard drive.  I believe it's pin 6 of the
larger ST506 interface; your disk may vary.  If you install a switch, the
extra wiring should probably be made as short as possible to avoid timing
problems.  This is the first thing I did when I bought my PC clone.

The neat thing about this is that due to disk buffering you can write a
file to the hard drive and MS-Dos thinks the file is really there until
the next time you do a directory, a side effect of which is that the disk
buffers get flushed.   Note that since it's possible to confuse MS-Dos
thusly, it is HIGHLY RECOMMENDED that before you do anything like "chkdsk"
you reboot the machine and come up with clean buffers.

So you can hand me the nastiest virus-ridden kracked-by-kaptain-k00l game
disk and I can run it with impunity, because I have a write-protect switch
*and* a hard-reset button.  And you can bet that I use both when checking
out any unknown software.  Comments upon how this scheme could fail for
any *one-time* run of infected software are solicited.

_H*

------------------------------

Date:    Wed, 25 Apr 90 16:30:43 -0400
From:    Elizabeth Caruso <[e-mail]>
Subject: Anti-virus cleaning programs that are shareware (PC)

Can you inform me of good shareware products that clean IBM pc
viruses?  McAfee's Clean-up is too expensive for a university site
license.  Thank you!

------------------------------

Date:    Wed, 25 Apr 90 00:00:00 -0500
From:    "Richard Budd" <[e-mail]>
Subject: Kennedy Virus

A note to F. Skulason's 4/19/90 description of the Kennedy virus.
There was a punk rock group out of San Francisco called the Dead
Kennedys. Though their peak came around 1980, they still enjoy a cult
following today.  This may explain the type of person who dreamed up
this virus but may also indicate it will probably show up in other
countries as well.

Richard Budd
Marist College
Poughkeepsie, NY KLUB@MARISTB

------------------------------

Date:    Thu, 26 Apr 90 10:43:00 -0400
From:    [e-mail]
Subject: Writable Executables

Of course Aiken was at Harvard, not MIT.  My apologies to fair Harvard
(and those from MIT perverse enough to take offense).

To the little boy from Louisiana who still resides in me, all those big
Yankee schools look alike.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    Thu, 26 Apr 90 11:33:00 -0400
From:    [e-mail]
Subject: Writable Executables

>What's an executable?
>
>Oh, something that the computer executes. You don't want programs to be able
>to write into executable files. Sorry, it'll never happen.

Agreed.

>I'm sure, in fact, that given a little time I could infect your AS400
>(or whatever), at least with a REXX script (or equivalent).

I concede.  Nonetheless, it is interesting to note that a command
language script on an AS/400 is a typed object.  (I do not believe that
the REXX interpreter for the AS/400 has been shipped yet.)

>Yep. Command scripts. A fertile breeding ground for viruses. And how about
>Postscript files? You want to turn off write permission on all your
>fonts?

All too true.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    26 Apr 90 17:00:31 +0000
From:    [e-mail] (Chung Chui)
Subject: Possible virus? (Mac)

          This is for all you mac gurus (guri) out there. We havea mac se that
is doing some strange things. When we are at the desktop opening a folder
the name would be wipe out and if we are lucky enough to get to an application,
such as MS-word it would not respond to the typing. Instead it would type
repeated characters that it first acknowledges. I've tried using Virex 2.5 and
other anti-viral applications on the harddisk but onthing showed up. Could
someone please tell me what's going on. Thank you in advance.

------------------------------

Date:    Thu, 26 Apr 90 22:48:00 -0400
From:    <[e-mail]>
Subject: CMOS attackers (PC)

  I just had a chat with the SYSOP of a local BBS here and he told me
about a file that was recently uploaded to his system.  All this
information was provided to me from the SYSOP, so I haven't had the
chance to verify it yet.  This is what the SYSOP discovered:

The file was archived with PKPAK or PKARC, and the resulting ARC file
was modified in some way.  This modification was designed to somehow
attack a PC's CMOS memory when PKUNPAK was run on it.  Of courese this
would only happen on PC's with CMOS memory.  The SYSOP discovered this
by using a number of programs, including CHK4BOMB, on the archived
file.  He has already sent a copy of the program to a company (I
forget the name) for analysis.

Personally, I am a little skeptical about these claims.  I admit that
I don't know much about Phil Katz's archiving programs, but I would
think that modifications to ARC files wouldn't make PKUNPAK suddenly
start going after CMOS memory...  I'll be getting a copy of this file
in a few days however, and will be taking a look at it myself.  If any
of the "experts" (David Chess, John McAfee, etc.) would like to take a
look at this thing I'll be more than glad to send out copies when I
get it.  Just e-mail me at one of the addresses below.

Bruce Pennypacker
[e-mail]
[e-mail]

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest   Monday, 30 Apr 1990    Volume 3 : Issue 83

Today's Topics:

re: Write-access to Executables
re: *really* fail-safe virus protection?
Re: New Virus? (PC)
re: *really* fail-safe virus protection
RE: Virus protection for OS in ROM
Mainframe viruses
Re: Possible virus? (Mac)
New files to MIBSRV (PC)
virus-l reply
Public Domain/Shareware Anti-Virus Tools for IBM PC
Re: Update to Memo on Computer Viruses in Commercial Products
1704 Version B (PC)
Re: *really* fail-safe virus protection

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    27 Apr 90 00:00:00 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: re: Write-access to Executables

"Pete Lucas" <[e-mail]>:

>                      It seems to me that *no* executables should be
> 'writable' by *any* program under normal circumstances.!.!   ...
> Now when you make a change to the source, you recompile and re-link,
> and if you know what you are doing, *ERASE AND RECREATE* the executable
> module.

Isn't the power to erase-and-recreate functionally the same as the
power to alter?  If something has munged an executable by reading it
in, erasing it, and re-creating it, the relevant consequences will
be just the same as if it had directly patched it on disk, yesno?
Are there operating systems that allow you to mark files as subject
to erase-and-recreate, but not subject to zap-in-place?  (That's
just a curiousity question; a virus can happily use either method.)

The power to erase-X-and-then-rename-Y-to-X is another functional
equivalent to bytewise write access...

DC

------------------------------

Date:    27 Apr 90 00:00:00 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: re: *really* fail-safe virus protection?

[e-mail] (*Hobbit*):
> Finally someone else comes up with the *correct* solution! ...
> Simply opening this line prevents any writes to the hard drive. ...
> Comments upon how this scheme could fail for any *one-time* run of
> infected software are solicited.

Well, a virus that infected the software while it was on someone
else's machine could decide to go off (because of the date or
whatever) and mess with your data files (which can't be readonly, in
general?).  But it's quite true that a virus can't spread to your
programs if they're all on a readonly medium whenever the virus has a
chance to be in control.

Why are only one-time runs interesting, though?   Most software gets run
more than once.   If you really do power down the machine before ever
flipping the write-protect switch off, and only run utterly trusted
software in that state, you're quite safe.   Utterly trusted software
is hard to come by, though!   *8)   If a virus ever gets to run while
the switch is off, or is ever still around in memory or whatever while
the switch is off, you're no longer protected.   No amount of testing
can reliably determine that a program deserves to be utterly trusted;
viruses can spread as rarely as they like (the original carrier of the
DataCrime had a month or so's delay before it started spreading).

This isn't to say that a write-prot switch for the hard disk is a
bad idea; if I got along better with hardware, I'd put one in myself.
But I'd suggest using it along with other anti-virus measures
(scanners, modification detectors, backups, etc), and not relying on it
exclusively.  I don't think it's *the* solution to the problem...

DC

P.S. The ultimate solution is of course John McAfee's "spackle".
     But it's difficult to get much actual use out of a
     properly-spackled computer, unless you have a door you want
     held open...

------------------------------

Date:    27 Apr 90 17:33:09 +0000
From:    [e-mail] (Mark Medici)
Subject: Re: New Virus? (PC)

Did anyone think of checking for a batch file called 123.BAT on this
system?  Or looking around on the disk with Norton Utilities (or some
such) to try and locate the file that contained some of the text that
was displayed.

This sounds more like a the type of non-damaging pranks I've played
(and have had played on me) than a a virus/worm/Trojan-horse.
Unfortunately, since the disk was wiped, we will probably never know.

- ----------------------------------------------------------------------------
Mark Medici/SysProg3 * Rutgers University/CCIS * [e-mail]
- ----------------------------------------------------------------------------

------------------------------

Date:    Fri, 27 Apr 90 10:45:10 -0700
From:    teda!RATVAX.DNET![e-mail] (George Roberts)
Subject: re: *really* fail-safe virus protection

> I.e. the write gate.  This is an active-low line from the controller to
> the hard drive which when disabled "floats" high.  Simply opening this
> line prevents any writes to the hard drive.  I believe it's pin 6 of the

WARNING!  Although TTL logic floats high when open, it can (and often
will) go low for a few microseconds (due to cross talk on the chip?).
I've been burned a few times when I thought some signal would float
high. I highly recommend that you use a pullup resistor to +5V (if you
don't already have one).  The value of the resistor would depend on
the drive strength of the chip on the other side of the switch.  5000
ohms will work for most cases: chips with an IOL MIN of 1 mA or more.

I would hate to see the write signal go low even for just a micro second
when the head is over some random part of my disk!  It may only happen
on rare occasions, such as when someone turns on a heavy appliance on
the same circuit.  It may only affect 1 bit (or none).

                                       - George Roberts
                                       ...teda!ratvax.dnet!roberts

------------------------------

Date:    Fri, 27 Apr 90 16:27:39 -0400
From:    Arthur Gutowski <[e-mail]>
Subject: RE: Virus protection for OS in ROM

>With the entire OS in ROM, there is no
>>longer a need for executable code the the partition/boot record
>>...
>What do you do for minor updates or patches, though? --a chip swap would
>be frighteningto joe_user for every minor updgrade/bug fix though.  There
>has been some talk in the past about moving the standard libraries and
>handlers into ROM.  Maybe in 1.5 :)

>Stephen Okay

Well, back to my origional misconception about Amigas and using EPROMs.
Even though they don't (yet), how much more of an undertaking, and how
much would it boost the cost, to start incorporating EPROMs into future
hardware for OS.  We have the technology, why not start using it?

EPROMs, with an external switch, Could enable you to install a new
versions/updates/bug fixes without a major kinipshin by owners.  Again,
this makes the assumption that the distribution diskettes are clean.
Another limitation would be the amount of writes you were able to do
before frying the EPROM chip; I dont know hardware that well, so I have
no idea what a reasonable estimate would be.

Amiga appears to have its act together more than most PC/compatibles and
Macs in that at least the low-level boot is done in ROM.  Hopefully they
will implement standard libs/handlers in the same way.  What about interrupt
vectors too?  I dont personally see any reason for modifying standard OS
interrupts (except with version updates); reserved/user programmable vectors,
if needed, can still be implemented the old way. Hmmmmmmmmmm

Art
-
 -==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==
\c-
  /=====\   Arthur J. Gutowski, System Programmer
 :  o o  :  MVS and Antiviral Group / Tech Support / WSU Univ. Computing Center
 :       :  5925 Woodward; Detroit MI  48202; PH#: [phone]
 : ----- :  Bitnet: AGUTOWS@WAYNEST1   Internet: [e-mail]
  \=====/     Disclaimer:  I think, therefore I am...(maybe).
 Have a day.

------------------------------

Date:    Fri, 27 Apr 90 16:44:46 -0400
From:    Arthur Gutowski <[e-mail]>
Subject: Mainframe viruses

David Chess:
>...viruses don't have to get around security systems to spread; they
>spread by writing to objects that they are authorized to write to.

Let me restate my point:  properly implemented and audited security
systems tend to *restrict* the spread of viruses.  I'll concede that
security systems alone don't do the trick; you have to have people
who use the mainframe system educated on how to protect themselves
from being tromped on by others.  This, of course, does not prevent
them from stepping on themselves, but if they cannot write to another
persons (or the systems) object libraries, he cannot spread the virus
to someone else, can he?  Mainframes use something that most pc-type
architectures dont--protected memory.

When a task enters the system under MVS or VM, the OS sets up an
address space bounded in memory for that task (batch job, TSO user,
etc.)  That address space cannot be modified by other address spaces
nor can it modify other address spaces (except for normal operator
commands like display, cancel, etc).  Forget security subsystems for
the moment, this is supported solely by the OS.  Under this type of
system, there is *no way* for a normal address space, regardless of
whether he is a "super-user", security id, or whatever, to even
address outside of his own address space.  The system maintains a set
of page tables, and all of your addressable storage is maintained
through these tables.  They can only be modified through the system.
If you need more memory, the system grabs more (if available), and
sets up another pagetable entry for you.  When your task terminates,
the system deletes all of your entries, and returns all your memory to
the free memory pool.  None of this can be accessed directly by the
user, period.  There is no way for viral code to get control of system
functions in this way.  Now there are some special utilities out there
that run under the OS that allow you to view or modify global storage
areas, but these should be (and are at our installation) monitored for
such activity.  The only other way to introduce viral code into the
system is to have system programmer abilities and access to make
changes to the system load libraries.  Not an easy task.  Now, as Dave
and others have pointed out, this type of knowledge is limited
comparative to PCs, and the casual hacker is discouraged from such
targets.  Those that do have the ability and would be using it for
dastardly ends, once caught would find themselves without the second
necessary element--access.

With regard to file copying, copy utility programs aren't
other-modifying in the sense that I get from your posting, Dave.  As
far as a copy utility is concerned, all you're copying is pure text.
A copy program don't know the difference between data and object, it
just copies bytes from file1 to file2.  When invoked, it makes a call
to the system to allocate file2, then it writes.  When it's done, both
files are closed, and the program terminates.  Now on a PC,
object/data distinctions are easy (*.COM, *.EXE vs. *.DAT, *.DBF).  On
MVS and the like, that distinction doesn't exist.  The only time the
system knows the difference between the two is when it's told to
EXECute a file.  If it's not object or macro or script langauage,
you'll know almost immediately.  VM is different from MVS in that the
MODULE and EXEC filetypes still exist to make things easy for you.
Now, you could copy a program that contains a virus to another file,
but again, whether you you infect someone else in this manner depends
on what accesses are granted through your security subsystem.

Again, mail viruses are a different story altogether.  And I agree
with the many recent postings about script viruses being a "fertile
breeding ground".  But whether that breeding ground exists beyond the
single user is dependent on the file sharing (e.g., through mailings)
between users (a Christmas tree, neat, huh?) and accesses granted
throughout the system.

>Intersting discussion whilst I was on vacation!

I agree, let's keep it going.

 Arthur J. Gutowski, System Programmer
 MVS and Antiviral Group / Tech Support / WSU Univ. Computing Center
 5925 Woodward; Detroit MI  48202; PH#: [phone]
 Bitnet: AGUTOWS@WAYNEST1   Internet: [e-mail]
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 "He's learning to match the feat of the Old World Man
  He's learning to catch the heat of the Third World Man
  He's a New World Man"

------------------------------

Date:    Fri, 27 Apr 90 22:10:56 -0400
From:    Yary Richard Phillip Hluchan <[e-mail]>
Subject: Re: Possible virus? (Mac)

I hope this answer doesn't insult your intelligence, but if you're
using a system (or control panel) more than a year old you've got the
problem.  There was one setting of the keyboard- fastest repeat rate,
shortest delay until repeat, I think- that would take any keypress and
repeat it for as long at is was held down.  That plus a sticky key
could do it.

Course I could be wrong.

------------------------------

Date:    Sat, 28 Apr 90 13:32:35 -0500
From:    James Ford <[e-mail]>
Subject: New files to MIBSRV (PC)

The following files have been downloaded directly from Homebase BBS on
4/27/90 at 8:00pm (April 27).  These file have not been re-zipped in any
way, just downloaded, transfered to a floppy, and uploaded to the RT.

The files they replace will remain on the server for approximately one
week, in case requests for them are pending at BITFTP@PUCC.


At MIBSRV.MIB.ENG.UA.EDU (130.160.20.80) in pub/ibm-antivirus
- ------------------------------------------------------------------------
CLEANP62.ZIP   46990  CLEAN-UP V62 Virus removal program.     (04-25-90)
SCANV62.ZIP    45680  VIRUSCAN System Scanner V62.            (04-25-90)
VSHLD62.ZIP    33323  VSHIELD Infection Prevention TSR Prog.  (04-25-90)
FSHLD12.ZIP    34693  FILE SHIELD - For Software Developers.  (04-27-90)
NETSCN62.ZIP   34654  NETSCAN Network Version V62             (04-25-90)
VSUM9004.ZIP   35857  Virus Information Summary Listing       (04-18-90)

- ----------
The man who has accomplished all that he thinks worthwhile has begun to die.
- ----------
James Ford -  [e-mail], [e-mail]
              THE University of Alabama (in Tuscaloosa, Alabama  USA)

------------------------------

Date:    Sat, 28 Apr 90 12:22:56 -0500
From:    [e-mail] (TSgt William Haley)
Subject: virus-l reply

The new PC Virus that Don Kazem writes about in Vol 3 Issue 82 is a
prank/panic/trick program that will put the message on then proceed to
act as if it is formating all hard drives in the affected system.  To
the best of my knowledge it does no harm to anything except the
onwer's peace of mind and general condition of his/her heart for a
brief period of time.  I have a copy of the program if anyone is
interested in obtaining same.  Please contact me directly and not thru
this list.  Below is Kazem's message less the screen shot:


>From:    Don Kazem <[e-mail]>

I received a call today from one of the local chain food stores about
what could be a new virus. Since they have no connection to the
network, I offered to post this.

A user was running Lotus (by invoking 123.exe), and after a file
retrieve, the virus was triggered. The following message was
displayed: (The spelling errors are the same as they appeared).

(edited out)

After a while, the words "JUST KIDDING" appeared, and everything went
back to normal. Although, it appeared as though there was no damage,
they ran Wipedisk, and installed everything from the original disks.

They ran SCAN61 both before and after reinstalling the software, and
SCAN did not find anything.

The have a backup of the hard disk, before they ran Wipedisk, and are
willing to forward copies of their executables to researchers (lawyers
permitting).

Has anyone heard of this?

Don Kazem
National Academy of Sciences
[e-mail]
-
 ------------------------------------------------------------------------------
\c-
W. Rusty Haley, TSgt, USAF           | This space reserved for future info.   |
2852 Security Police Squadron/SPPC   |                                        |
McClellan AFB, Sacramento, CA. 95652 |                                        |
INTERNET:[e-mail]|                                        |
USS:[e-mail]               |                                        |
ALLIN1: HALEY.RU                     |                                        |
AUTOVON:633-5523 COMM:916-643-5523   |                                        |
-
 ------------------------------------------------------------------------------
\c-

------------------------------

Date:    30 Apr 90 01:13:47 +0000
From:    [e-mail] (Joseph Young)
Subject: Public Domain/Shareware Anti-Virus Tools for IBM PC

I have a couple of questions about Public Domain or Shareware anti-
virus software.

1. I'm confused about the John McAfee product line ... is it share-
   ware or not? As you can see, I'm from an Australian University and
   we are interested in using SCANRES (/VSHIELD) on an institution-
   wide basis.

   Information we have received from McAfee Associates,
   suggests we need to buy a site/ corporate licence costing $5,925
   (US) for say 500 copies (that's about $7,400 to us down under).

   A recent posting forwarded by Alan Roberts from John McAfee talks
   about 'changes to the SCAN shareware product line'.

   So, do we need a SCANRES license or is it shareware, am I
   talking about two sets of different products or is the price
   above the actual shareware price or what? If we need a
   license, are we talking a site license or corporate license for
   a multi-campus educational institution?

2. Are there any other public domain/ shareware products similar to
   SCANRES/ VSHIELD we should look at?

3. Finally, we're running Novell PC networks. What virus
   protection software are people using in this area?

   Again, McAfee Associates have NETSCAN for $2,000 (flat fee)
   according to their product listing. Can anyone help with more
   information about this? Do you need to buy a copy of NETSCAN for
   each network you want to protect?

   Are there any other anti-virus tools we should be looking at
   for Novell PC networks?

Any information at all on any of the above would be greatly
appreciated. If there is enough interest, I'd be only too happy
to summarise for the net.

Joseph Young, Queensland, Australia.
E-Mail: [e-mail]

------------------------------

Date:    30 Apr 90 03:33:19 +0000
From:    [e-mail] (Woody Baker @ Eagle Signal)
Subject: Re: Update to Memo on Computer Viruses in Commercial Products

Gimme a break.  No wonder our fine government is so screwed up.  This
is one of the worst cases that I have seen of complicating a written
communication.  Simplify this stuff.  Certainly you can eleminate most
of the jargon.

There have been reports of commercial packages infected with viruses.
Below is a partial list of them.  There are legitimate uses and needs
for public domain and shareware.  Should be Army start random spot
checking for these?

The above 4 sentences are the gist of the message, and the entire
message other than the list could be done in 1 clear paragraph, rather
than "missions"...etc et.

Cheers
Woody

------------------------------

Date:    Mon, 30 Apr 90 09:53:57 -0500
From:    Ghost <[e-mail]>
Subject: 1704 Version B (PC)

Hi out there,

we found the 1704 virus version B at RHRZ Bonn, Germany. We got it
from a person who learned SPSS PC+ in our pool. The infection software
was MIPS.COM, a program what shows the speed of the computer. He give
it to the course leader and he give it round in our computing center.
Because of the age of the virus i didn't found any comments to it. The
infection was 10 month ago, and we didn't know it. Some machines,
where public domain software was tested, were clean. They are clean
yet. I tried McAfee's CLEANP61 to kill the virus out of the software
packages without destroying them, but the software didn't run. I
think, i make an error, but i there is somebody else, whop know this
problem, please describe it.

So long

Thomas Friedrich
RHRZ Bonn, Germany
([e-mail])

------------------------------

Date:    30 Apr 90 10:15:43 +0000
From:    [e-mail] (Solitair)
Subject: Re: *really* fail-safe virus protection

[e-mail] (*Hobbit*) writes:
>   ... changed the keyboard key lock in that way that it now
>   controls the writing electricity cables of one hard disk so that no
>   writing operation can be done on this (bootable) hard disk.
...
>If you install a switch, the
>extra wiring should probably be made as short as possible to avoid timing
>problems.

Well, actually the wire needn't be so very short for a ST506 cable.
The specs say the total cable length may be 3m (=10 ft), and you don't
have to worry about EMI (electro magnetic interference) because the
actual write gate signal doesn't carry such high frequencies.
- --
Sincerely,                         | [e-mail]
           Stephen R. van den Berg | ...!uunet!mcsun!unido!rwthinf!cip-s01!berg

------------------------------

End of VIRUS-L Digest
*********************Subject:  VIRUS-L Digest V3 #105
From: [e-mail]

VIRUS-L Digest   Friday,  1 Jun 1990    Volume 3 : Issue 105

Today's Topics:

getting a list of all LISTSERV groups
Mac virus alert vendor product (forwarded) (Mac)
Re: File tranfser of software--A way to curb commercial infections?
Re: Military Viruses
write-protection viruses
Legal aid for hackers?
help against virus needed (PC)
Re: Does write-protection work? ...for Mac

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Thu, 31 May 90 13:30:52 -0500
From:    "Mark R. Williamson" <[e-mail]>
Subject: getting a list of all LISTSERV groups

On Thu, 31 May 90 13:52:08 EDT you said:
>VIRUS-L Digest   Thursday, 31 May 1990    Volume 3 : Issue 104
...
>I don't know whether either a GRAMMAR-L or a LATIN-L exist.  The
>LISTSERV@BITNIC would be a good source to check, however.  Send mail
>to it stating "LIST", and it will send you a *big* list of lists.]

That's the _small_ list of lists handled directly by LISTSERV@BITNIC.
For the *BIG* list of lists handled by _all_ LISTSERVs, send the command
"LIST GLOBAL".  It's >2000 lines long!

Just for your information.

Mark R. Williamson, Rice University, Houston, TX; [e-mail]
- -------------------------                         MARK@RICEVM1 on BITNET

------------------------------

Date:    Thu, 31 May 90 14:22:40 -0700
From:    [e-mail] (Rollo D. Rogers)
Subject: Mac virus alert vendor product (forwarded) (Mac)

Original-From: [e-mail] (Chuck Hoffman)
Original-Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Original-Subject: ALERT about VIRUS in vendor-distributed product
Original-Date: 31 May 90 18:30:43 GMT

   On May 25, I received the Diskworld diskette for May from Softdisk
Publishing in Shreveport, Louisiana.  I run Virex 2.6 (among others) which
intercepted the mount of the diskette and gave me a warning that the
diskette has a known strain of the WDEF virus.  Naturally, I chose the
"Eject" option of Virex, so the mount never was completed.

   WDEF is simple, but difficult.  Simple in that it lives in the
invisible desktop file of each disk or diskette.  So it can be eliminated
by rebuilding the desktop file by holding down the command and option keys
during the mount (or during startup, for an internal hard disk or SCSI).
Difficult for the same reason.  The gurus tell us that, if you are unaware
of the virus, by the time you see the diskette icon on your desktop
display, ALL the other disks (including internal and attached SCSI) will
already have been infected.  I did a controlled experiment of my own a few
months ago, and found that this was true.

   I called Softdisk Publishing to report my experience, and spoke with a
woman who said they already knew of the virus problem.  She suggested that
I simply reinsert the disk while holding down the command and option keys
to rebuild the desktop file, but I asked her to send me a clean copy of
the diskette instead.

   Lesson?  "Doesn't matter if the box is snazzy.  Use virus detectors to
protect your azzy."
- -Chuck

- - Chuck Hoffman, GTE Laboratories, Inc.
[e-mail]
Telephone (U.S.A.) 617-466-2131
GTE VoiceNet: 679-2131
GTE Telemail: C.HOFFMAN

------------------------------

Date:    Thu, 31 May 90 11:32:14 -0500
From:    [e-mail] (Gary Heston)
Subject: Re: File tranfser of software--A way to curb commercial infections?

ctycal![e-mail] (Terry Ingoldsby) writes:

> I've always felt that networks are less likely to transmit viruses
> than floppy disks because it is more likely that the culprit will be
> caught.  I grant that games can be played with the signatures, etc.,
> but chances are that some sort of log files are kept by the system
> administrators about what came in, and when.  Although difficult, in a
> crisis there is at least some hope that the dissemination path used by
> the virus can be discovered.  Although not foolproof, this should act
> as somewhat of a deterrent to virus writers.

Due to a company policy (which I disagree with), I am not able to
discuss any infections which may or may not have occurred here.
Consequently, if I have any real examples, I can't cite them.

Networks can propagate a virus thru several avenues, particularly if
the netadmin is inexperienced and hasn't quite got file protections
for network executables set correctly. If user Fred logs in to a
network, works a while, and runs a infected game during lunch without
rebooting (whether from a local hard drive or floppy), the virus will
try to infect the next program executed via the net. If user Barney,
who carefully logs off during lunch, logs back in and runs the infected
program, it will try to infect Barneys' local drives as well (it should
have already gotten established on Freds').

Now, we have a logfile that shows Fred, Barney, and 30 other users
ran this particular piece of software, at various times during the
day, and probably more than once. What points to the infection
source?

If there are any publicly writeable areas where users can put
executables, there is an even larger gaping hole an infection
can enter thru. (Users like to have these types of areas.)

This can be controlled somewhat by the netadmin getting the
setup correct; however, this is a somewhat optomistic hope in
view of the complexity of network software and the limited
training new admins get (I'm trying to learn Novell right
now; the company decided nobody needs to go to seminars for
anything). It's difficult to track down a security hole when
the boss is asking hourly "Why isn't the network up yet?".

The possibility of installing infected shrink-wrap software
is also a big hazard now; people who thought they were safe
by prohibiting public domain or shareware aren't.

I think the biggest thing that can and must be done is
education. Admins need it, users need it, and managers need it.
Training users to check software before they run it, scan
their drive periodically, and recognize early signs of infection
is necessary. Training admins to check EVERY piece of software
prior to installation, no matter how many layers of plastic it
was (or wasn't) wrapped in, along with safe setups. Teaching
management that this really is necessary, not just a waste
of resources, and you really do need that many tapes for
backups. Etc.

> Floppy disks are almost untraceable since they carry *no* copy history,
> *no* history of what machines they visited and almost no means of
> identifying the offender.

True. However, the person holding it can explain why they were
running the software without checking it....

>   Terry Ingoldsby                ctycal![e-mail]
>   Land Information Services                 or
>   The City of Calgary       ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb

Incidentally, the stated reason for the do-not-discuss policy was
to prevent stock price manipulation. I still disagree, I don't think
a infection report would affect a stock price more than a few cents,
if at all. I didn't win the argument, though.

- --
    Gary Heston     { uunet!sci34hub!gary  }    System Mismanager
   SCI Technology, Inc.  OEM Products Department  (i.e., computers)
"I think, therefore, !PANIC! illegal protected mode access attempt
Memory fault: core dumped

------------------------------

Date:    Thu, 31 May 90 22:35:20 -0500
From:    [e-mail]
Subject: Re: Military Viruses

     I posted Jim Vavrina's posting regarding the Military Virus
story (Virus-L Volume: 3  Issue: 93) to the RISKS forum (Volume
9  Number 92), where the matter was being discussed as well.  In the
following issue of RISKS (Volume: 9  Number: 93) Rory J. O'Connor of
the San Jose Mercury News, the author of the article that started the
discussion, posted his response to Mr. Vavrina.  That response,
excerpted from RISKS 9.93, follows:

 ------------------------------------------------------------------------
Reply-to: [e-mail]

RISKS-LIST: RISKS-FORUM Digest  Monday 21 May 1990   Volume 9 : Issue 93

 ------------------------------

Date: Sun, 20 May 90 14:25:39 PDT
From: [e-mail] (Rory J. O'Connor)
Subject: Military Computer Virus Contract (RISKS-9.92)

I'm the reporter at the San Jose Mercury News who wrote the story on the Army's
SBIR proposal regarding computer viruses. I feel I must respond to the charge
made by Mr. Jim Vavrina of the Army Information Systems Software Center that I
mis-identified myself while researching the story. That assertion is false.

At all times, as is standard practice among professional journalists, I made it
clear to everyone I called or interviewed that I was a newspaper reporter
working on a story about this proposal. When I reached a woman named Joyce
Crisci at Ft. Monmouth, NJ, who identified herself as the project
administrator, I identified myself as a reporter. When she attempted to tell me
how to apply for the available funds, I felt she might have failed to
understand that, so I again told her I was a reporter working on a story for my
newspaper. She then answered most of my questions, but made it clear she would
not discuss any technical details nor provide me with the names of the
engineers who had written the project. The reason, she said, was that if such
information appeared in my story, it could prejudice the bidding process.

Indeed, at the conclusion of our interview, she verified the spelling of her
name and gave me her (rather complicated) mailing address and requested I send
her a copy of the article when it appeared in the newspaper.

I'm sorry Mr. Vavrina never called me to ask my side of the story about this
interview. If Mr. Vavrina thinks my story about the virus was in some way
factually incorrect, or did not fully describe the Army's project or reasoning,
I'd be happy to talk to him about it. I can be reached at [phone], or at
MCI Mail mailbox 361-2192, or at the San Jose Mercury News, 750 Ridder Park
Drive, San Jose, CA 95190. Anyone else who would  like to discuss this story,
or the topic of computer viruses in general, may also contact me there.

Rory J. O'Connor, Computing Editor, San Jose Mercury News

 ------------------------------

------------------------------

Date:    Thu, 31 May 90 21:13:27 -0400
From:    [e-mail] (Simson L. Garfinkel)
Subject: write-protection viruses

Write protection on the Apple II computer is done in software; on this
machine a virus could overcome write-protection on a floppy disk.

I once used a program that "degaused" a floppy disk in 15 seconds or
so on the Apple II, even if the floppy disk was write protected.

------------------------------

Date:    Fri, 01 Jun 90 08:05:30 -0400
From:    [e-mail]
Subject: Legal aid for hackers?

       I'm sending along the following from yesterday's Washington Post.  I'd
like to know Cliff Stoll's (The Cuckoo's Egg) reaction!!.

The Washington Post, Business Section, May 31, 1990
By Willie Schatz

     Mitchell Kapor, inventor of Lotus 1-2-3, the world's most popular
financial software package, is considering backing a national effort to
defend computer hackers against prosecutions resulting form Operation Sun
Devil, a two-year Secret Service investigation of potential computer fraud.
     Operation Sun Devil was disclosed early this month by the Secret
Service, which conducted 27 searches of suspected hackers' homes and
offices, confiscating 23,000 computer disks and 40 computer systems.  There
have been three arrests thus far.  The Secret Service said the hackers who
were the target of the probe are individuals who had gained unauthorized
access to company computer systems--including one at American Telephone &
Telegraph Co.--or had stolen and distributed software programs that
belonged to major corporations.
     In an interview from the Cambridge, Mass., headquarters of his new
company, ON Technology, Inc., Kapor said he thinks the government probe is
misdirected.  He said it is damaging technological innovation and
dissemination of information through the ubiquitous electronic message
networks called bulletin boards that are the hackers' prime method of
communication.  Kapor intends to announce tomorrow whether he will pay for
all or part of the hackers' legal defense.
     "It's plausible that there's a witch hunt going on," Kapor said.  "I'm
concerned that hackers' civil liberties are being violated [by the Secret
Service].  I'm concerned these kids--which is mostly what hackers
are--aren't getting a fair shake in the legal system.  They don't have
access to legal counsel that would let them adequately defend their
rights."
     Sources said Kapor is reviewing a proposal he received yesterday from
two law firms that asks him to help finance a $200,000 hackers' legal
defense fund.  Lawyers involved in the matter plan to provide much of their
legal work free.  The proposal before Kapor also includes a program to
lobby Congress to change the computer fraud law and a public education
campaign about hackers.
     "Sun Devil gives me a funny feeling in the pit of my stomach," Kapor
said.  "There's an incongruence between the language of the Secret Service
and the acts and attitudes of hackers.  I understand and know that
[hackers'] kind of mentality.  You don't want to use an A-bomb to kill a
fly.  There has to be an appropriate response and understanding of what's
at issue.  I'm lacking confidence that that's there."
     Earlier this month, Garry J. Jenkins, assistant director of the Secret
Service, said Operation Sun Devil revealed that an "alarming number of
young people" exploit computers through credit card fraud, unlawful
placement of free long-distance phone calls and other criminal activities.
In an interview, Dale Boll, an assistant special agent in charge of the
Secret Service's fraud division, defended the government probe.
     "We have not declared war," Boll said.  "Computer crime is a serious
offense, but we don't overreact.  There's no tendency for overkill.  We
were given these laws to enforce and we're doing the best we can.  We
prefer to work more hardened criminals.  The government didn't prosecute
hackers when they were juveniles.  But now they're growing up and doing
more serious things."
     The damage form the government's aggressive law enforcement efforts,
according to Kapor, is a "chilling effect" on the flow in information among
computer designers and programmers.  Kapor contends that if the people
responsible for operating computer bulletin boards are held responsible for
information posted on their boards, hackers will stop using the boards.
     "It's a gigantic social experiment in progress," Kapor said.  If the
government "cuts it off at the knees by inappropriately ruling [that the
bulletin board operators are guilty of fraud], they're cutting off their
own future."
     John Barlow, a dedicated hacker and a lyricist for The Greatful Dead
band, said he already is committed to financing the hackers' cause.  "I'm
going to chip in to secure them legal council and so is Mitch," Barlow said
from his home in Pinedale, Wyo.  "I'm sure the [Secret Service's] assault
is having an effect.  It's turning mischievous kids into high-tech
criminals.  These hackers are explorers, not criminals or vandals.  They're
exploring a new information frontier.  It's a reincarnation of what
happened with the settling of the Old West, only in the computer sphere."
     Government officials have a different view.  "Many computer hacker
suspects are no longer misguided teenagers mischievously playing games with
their computers in the bedroom," the Secret Service's Jenkins said.  "...We
will continue to investigate aggressively those crimes which threaten to
disrupt our nation's business and government services."

------------------------------

Date:    Fri, 01 Jun 90 17:45:17 +0700
From:    GUNNAR RADONS <[e-mail]>
Subject: help against virus needed (PC)

hi pple,

It looks as if we have been hit by a virus. As far as I could find out
from the people which reported the problems to me, the normal behaviour
seems to hinder programs from running properly. Programs who ran fine
before suddenly don't find subroutines or other things, but will run ok
after they've been restarted.
Also the virus once showed the contents of the disk directory as a sub-
directories  which repeated on and on. A later look did not show any
subdir. Also checking after rebooting didn't show any additional subdirs
The same problems where reported from another institute here a few weeks
ago. It might be that the virus hooks itself into some free space of the
command.com, but this is a pure guess right now.
If this sounds familiar to you  and if you now a way to find the virus
to cure the programs, please let me know.
Send your comments to s46 at dhdurz1 please.
                      ==============
Bye, Gunnar Radons

------------------------------

Date:    Fri, 01 Jun 90 17:58:48 +0000
From:    [e-mail] (Robert Minich)
Subject: Re: Does write-protection work? ...for Mac

[e-mail] (Alberto Sulaiman Sade Junior) writes:
| SOME TIMES AGO I READ THAT IS POSSIGLE A VIRUS INFECT A DISKETTE
| PHISICALLY PROTECTED.  I KNOW IT IS AN OLD DISCUSSION BUT IS IT REALLY
| POSSIBLE ?
|
| [Ed. Yes, this discussion has come up a few times before.  After much
| heated discussion, the consensus was that (on a PC), the write
| protection is implemented by hardware in the floppy disk drive
| (according to the IBM Tech. Ref. schematics).  At least in the case of
| PCs, I urge us to consider this matter closed unless someone can come
| up with conclusive proof to the contrary (i.e., send me a piece of
| source code that proves it).]

  Let me add that all macintoshes implement write protection for
floppies through a hardware mechanism.

- --
| _    /| | Robert Minich             |
| \'o.O'  | Oklahoma State University |
| =(___)= | [e-mail]   |
|    U    | - Bill sez "Ackphtth"     |

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 105]
******************************************
VIRUS-L Digest   Tuesday,  5 Jun 1990    Volume 3 : Issue 106

Today's Topics:

clearing ps/2 pw, faces on screen (PC)
removing Stoned from harddisks (PC)
New files to MIBSRV... (PC)
123nhalf virus (PC)
Listserv with virus information. (PC)
Re: mainframe viruses
Intentional Virus(es?)
Call for definition for common computer beasts (ie viruses...)
Mac Happy Face turns into a Devil... (Mac)
Documented mainframe viral attacks
SCAN Version 63 (PC)
Re: File tranfser of software--A way to curb commercial infections?
Re: How to reset CMOS configuration that prevents booting? (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    01 Jun 90 16:02:55 +0000
From:    "The.Gar" <[e-mail]>
Subject: clearing ps/2 pw, faces on screen (PC)

Dimitri -
    I can't help you with your problem, other than to tell you that
IBM's recommended procedure for a forgotten password USED TO BE to
remove the battery from the motherboard (I had an original PS/2 70.)
THIS HAS CHANGED, however, and they now have a "trick" that let's you
quickly clear the password.  What one is now able to do, is unplug the
speaker connector from the bus adapter card, and plug it in in the
opposite direction.  PRESTO! Your password is cleared!
    I REALLY doubt this would work on non-IBM hardware, though.


Joest@DD0RUD81 -
    What you describe sounds very much like a practical joke program
that I have seen a dozen times around campus.  It is called FACES, and
is quite small  (about 3K I believe.)  What I would ask you to check is
whether your program does in fact set the KEYBOARD=GR?  If it does not
I would suggest that someone modified the FACES program to make it smaller
and has simply renamed it and copied it over your other program.

Later
THE GAR

------------------------------

Date:    Fri, 01 Jun 90 16:56:04 -0500
From:    martin zejma <[e-mail]>
Subject: removing Stoned from harddisks (PC)

During the last two months there were several asks how to remove
the STONED-virus from harddisks. The solution is quite easy :

1) Boot from a clean write-protected floppy disk

2) Use a disk-monitoring program
      ( the good old DEBUG would make it also, but better are programs
      like the Norton Utilities )

3) Read sector 7 from the boot track
      ( Exactly : Head 0 , Track 0 , Sector 7 )
   At the begin of this sector you should find the system description of your
   operating system ( f.e. DOS 3.3, PCDOS 4.00, etc) and the volume label of
   your harddisk.There is also the partition table viewable, but most people
   can't read it ;-) .

4) Write this sector over the infected boot sector of the harddisk
   ( that's Head 0 , Track 0, Sector 0  , just to make it failsafe).

5) Remove the floppy disk, and make a cold-boot from the harddisk.
   Now everything should work fine.

If you don't have backups from your harddisk, backup the infected disk,
the bootsector is not backed up like files, and the virus doesn't
infect files , just the boot sector.

All that stuff should work fine, because until now I heard nothing
about other variants of this virus floating around.  On disks which
you can't clean transfering the OS using the SYS A: Command this
operation works also, but the ORIGINAL sector is stored at Head 1 ,
Track 0, Sector 3 .

Hope this solves the nightmares with this virus.

( All errors included without extra-fee )

                                        sincerly yours,

                                        Martin Zejma

+--------------------------------------------------------------------+
|                                                                    |
|  Martin Zejma                           8326442 @ AWIWUW11.BITNET  |
|                                                                    |
| Wirtschaftsuniversitaet Wien --- Univ.of Economics Vienna /Austria |
+--------------------------------------------------------------------+

------------------------------

Date:    Sun, 03 Jun 90 16:46:06 -0500
From:    James Ford <[e-mail]>
Subject: New files to MIBSRV... (PC)

The following files have been added to MIBSRV.MIB.ENG.UA.EDU
(130.160.20.80) in the directory pub/ibm-antivirus:

scanv63.zip  - Latest SCAN. Scan files for several vir(insert_your_ending_here)
cleanp63.zip - McAfee's Clean-Up program.
netscn63.zip - McAfee's SCAN for networks
vshld63.zip  - McAfee's VSHIELD
shez55.zip   - Shez Version 55.

The files were downloaded from Homebase on June 3, 1990 at 2:00pm.
The files have not been re-compressed in any way.  Older version will
remain on MIBSRV until June 6, 1990 for possible pending requests at
BITFTP@PUCC.

For those who cannot FTP, send a one line mail message (help) to
BITFTP@PUCC for information on how to FTP via BITNET.

- ----------
Whether you think you can or whether you think you can't, you're right.
- ----------
James Ford -  [e-mail], [e-mail]
              THE University of Alabama (in Tuscaloosa, Alabama  USA)

------------------------------

Date:    Mon, 04 Jun 90 12:33:00 -0100
From:    Marco Colombini <[e-mail]>
Subject: 123nhalf virus (PC)

Hi people,
    it seems that a friend of mine has been infected by the 123nhalf
virus reported by IA96000 in september '89.
    Could you please give me more informations on it (where to find the
123scan.exe code, how clean up things, and so on...) together with some
news (if exist) on other lotus 1-2-3 viruses.
    Any information on the appropriate virus killer(s) is welcome too.
Many thanks.

Marco Colombini
IDPO at IGECUNIV

------------------------------

Date:    Mon, 04 Jun 90 09:17:30
From:    Eduardo Rodriguez S. <[e-mail]>
Subject: Listserv with virus information. (PC)

  Hi. In Virus-l v3-i103, there are two request for virus information:

>From:    [e-mail] ( STUG)
>Subject: Virus Information

>From:    <[e-mail]>
>Subject: additional request tag to 1813 virus sighting (PC)

  In our local listserv (LISTSERV@UCHCECVM), in the SOFT_L FILELIST
has been placed the Dr. Brunnstein Catalog (with Dr. Brunnstein
authorization). This catalog can be retrieved with this command:

  GET MSDOSVIR A89 SOFT-L
  GET MSDOSVIR 290 SOFT-L

  both can be send via MAIL, MESSAGE or simple FILE. To obtain a
list of all the files available in this FILELIST you can send:

  INDEX SOFT-L

  the description is in spanish. If anyone have some problem, can
contact me.

- -----------
She may be late.
- -----------
[Eduardo Rodriguez S]
[Universidad de Chile]
- -----------

------------------------------

Date:    Mon, 04 Jun 90 10:10:30 -0400
From:    Arthur Gutowski <[e-mail]>
Subject: Re: mainframe viruses

[e-mail] (Craig Harmer) writes:

>...wasn't there even something on Bitnet (i'm not sure)?  i suspect
>that MVS and VM have *more* holes than Unix, for the simple reason that
>there are less people around looking for holes to exploit.  far fewer
>people have access to the source, or machines that run it.  they cost
>more than $1 million each, after all.
>...{stuff about VM's frailties deleted}...

I believe you're referring to the infamous XMAS (or CHRISTMA) EXEC that
could in fact crash VM by filling up it's spool space.  But, as with any
other system, alert staff here were able to nip it in the bud *before*
VM came crashing down (similarly, we have been able to avoid XMAS clones
by making the operations staff aware of them as they appear).  It is my
intuition that any system that has a file transfer mechanism has to have
dasd to put files onto, and thus runs the risk of crashing when that dasd
area runs dry (I don't know, other systems may handle it better, e.g., by
rejecting files when spool space is dry; in fact, I think VM can be set up
in this way).  As for stepping all the way to class 'A' once you get beyond
'G', I really don't know; VM isn't my specialty.  But it seems to me that
there would be *some* measures against this built into the system.

I disagree with your premise about Unix vs. VM or MVS security, though.
MVS has been in development far longer than Unix has been alive (even
back beyond the days of MVT), and there are many shops that use MVS and VM
(IBM ain't making it on PS/2s alone).  Thus, these operating systems have
had much more opportunity for people to poke around in them.  Not to say
they are invincible, mind you, but I think they're less susceptible than
Unix.

As for the source being readily available, that was a matter of choice, and
one that should, and has, been stood by.  I wrote a shareware program with
a friend, and we decided not to distribute source because we felt it would
make it harder for someone to break our code that way.  For the same reasons,
I'm inclined to believe that building back doors and spreading viruses in
Unix is easier with the source readily available.  The technical knowledge
isn't as necessary as general programming knowledge if the source is there.

Again, it is just a matter of choice.  Unix was intended to be a programmer's
system; as such it does a great job.  With all systems, there is a tradeoff
between functionality and security, the trick is to find the right balance.

  /==="   Arthur J. Gutowski, System Programmer
 : o o :  MVS & Antiviral Group / WSU University Computing Center
 : --- :  Bitnet: AGUTOWS@WAYNEST1  Internet: [e-mail]
  \===/                                       [e-mail]
 Have a day.
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 "Please all and you will please none."   -Aesop

------------------------------

Date:    04 Jun 90 19:05:57 +0000
From:    [e-mail] (Richard W West)
Subject: Intentional Virus(es?)

I have had just the strangest thought about all of the commercial
products out there on the market that protect from viruses, for
example Symantec's Anti-Virus for the Macintosh -- a product that
"learns."  Did the thought ever occur to anyone that the possibility
is there for companies to make and distribute their own new viruses
just to keep purchases of their product up?  I mean the potential
there is great, and all of the benefits go to the companies.  Each
time a virus comes out, the companies soon follow the viruses with
their "vaccine".  Take my example of SAM.  Sure, the program allows
for definitions of new viruses, but you need to buy an update to the
program if you want to have the capability of removing the infection
from programs.  As with most other programs (the good ones), you have
to purchase a brand new version (an update) to combat the new virus.
This leaves a greater potential for companies to profit from the
creation of new viruses.

Hey, sorry.. it was just a thought.

- -Rich West
Siemens Corporate Research and Development
Princeton, New Jersey
Internet: [e-mail]

------------------------------

Date:    Mon, 04 Jun 90 19:59:50 +0200
From:    [e-mail] (Morton Swimmer)
Subject: Call for definition for common computer beasts (ie viruses...)

          I have been increasingly perplexed by the fact that there seems
to be little consensus on what the definition of the term
"Computer Virus" actually includes. This goes for other computer
"beasts" such as "Trojan Horses" and "Worms". I would be interrested
in hearing what other people think a virus is.

          Here are my own definitions:

Computer Virus: a non-autonomous program that has the ability to
copy itself onto a target.

Trojan Horse: an autonomous program that has a function unknown
(and unwanted) by the user.

Worm: a program or set of programs that have the ability to
propagate throughout a network of computers.

          Please note that both worm and virus definitions do not
include the possibility of a payload. This may or may not be a
weak point. Also note that the definitions of virus and trojan
differ greatly from how Cohen defines them. This is intentional
as I feel that Cohen's definition of virus is too broad (it can
include a normal program such as DISKCOPY!). I'm not happy with
my definition of worm myself. Also, (and this should be obvious)
none of my definitions are very formal.

NB:
          I feel it would be more economical if any contributors
would send their pet definitions directly to me. I will then
summerize and post them. (After the viruses vs. virii discussion
I caused, I'd rather not be the cause of any more of Ken's
aggravation. :-)) Here are my addresses (addressii?):

          [e-mail]
or        [e-mail]

(Yes, I know they are long, but what can I do about it?)

Cheers, Morton
Virus Test Center

 .morton swimmer..virus-test-center..university of hamburg....odenwaldstr. 9.
 ...2000.hamburg.20..frg........eunet: [e-mail].
 ...God grant me the solemnity to accept the things I cannot change/Courage to.
 .change the things I can/And the wisdom to tell the difference.Sinead O'Conner

disclaimer: does anybody read these things anyway?

------------------------------

Date:    Mon, 04 Jun 90 16:27:31 -0400
From:    [e-mail] (Pete)
Subject: Mac Happy Face turns into a Devil... (Mac)

I just experimented with a public Mac which wasn't
working too well. When I watched it boot up, the usual
smiling Macintosh icon turned into a devil with horns,
fangs and a long tail. I checked it with Disinfectant 1.8
and found nothing.

My questions are:

1) Is this a virus or is it some legitimate program I've
never experienced before?
2) If it is a legitimate program, shouldn't programmers start
considering the side effects of putting neat garnishes on their
software? I know several people who have been complaining
about hidden about boxes. Looks like all the fun is going to be
gone soon.

- -Peter

Peter Wayner   Department of Computer Science Cornell Univ. Ithaca, NY 14850
EMail:[e-mail]    Office: 607-255-9202 or 255-1008
Home: 116 Oak Ave, Ithaca, NY 14850  Phone: [phone]

------------------------------

Date:    04 Jun 90 18:51:08 +0000
From:    [e-mail] (Gordon Spoelhof)
Subject: Documented mainframe viral attacks

As an occasional browser of this newsgroup, I have noticed that discussions
surrounding mainframe viruses tend to be theoretcial in nature.

Questions:

1.  How many mainframe viral attacks are documented?
2.  How many incidents are reported/not reported?
3.  In general, how are the viruses introduced?
4.  What corrective measures had to be taken?
5.  What preventative measures are taken?
6.  What is the level of risk?

Discussion anyone?

Disclaimer:        "Neither my wife nor my employer endorse opinion according
                   to Gordi..."

Internet:          [e-mail]
Telephone:         [phone]
Secretary:         716-724-1365 (Sharon)
FAX:               716-781-5799
US Mail:           Gordon Spoelhof
                   CIS/ITM 2-9-KO
                   Eastman Kodak Co
                   343 State Street
                   Rochester, NY 14650-0724

------------------------------

Date:    Mon, 04 Jun 90 11:08:21 -0700
From:    [e-mail]
Subject: SCAN Version 63 (PC)

This is a forward from John McAfee:
==========================================================================

          Creating bogus VIRUSCAN programs is becoming an increasingly popular
pastime for underground hackers.  In the past two months 5 such programs have
appeared.  Three of them appear to be innocuous, but the bogus version 65
discovered in Israel was extremely destructive, and the version 72 reported
in the U.S. last week causes system crashes and file losses.
          I believe these problems are here to stay, and we can count on future
bogus appearances.  For this reason, it is important that all SCAN users
obtain their updates from reliable sources.  A reliable source, by my
definition, is one that obtains their copy directly from HomeBase.  If you
are unsure of your source, then do not use the program.  In any case, each
new release should be Validated before using.  When validating a new release
of SCAN, use your known good copy of Validate.  Do not replace your known
copy with the copy distributed with each release.  Validate has not changed
since it was first released and no changes are planned for the forseeable
future.  So once you obtain a good copy, hang on to it.  If you do not
currently have a copy, then download it from a known reliable source.  As
a final precaution, verify the validate numbers by checking the on-line
validation data base on HomeBase.  The numbers within the data base are
secure and cannot be tampered with.  These same numbers are published on
the larger public bulletin boards and some of the national networks.
          I have also been asked by a number of users to publish the validate
numbers on VIRUS-L.  Version 63 was released this past weekend and here are
the numbers:

SCAN.EXE    -  Size:46,535   Date:6-2-90  Check1:D30F   Check2:1F82
CLEAN.EXE   -  Size:58,835   Date:6-2-90  Check1:429C   Check2:062E
VSHIELD.EXE -  Size:40,987   Date:6-2-90  Check1:CCE7   Check2:01FB
NETSCAN.EXE -  Size:46,535   Date:6-2-90  Check1:2B07   Check2:0E87

John McAfee
408 988 3832 -voice
408 970 9727 -fax
408 988 4004 -BBS

------------------------------

Date:    04 Jun 90 18:15:33 +0000
From:    ctycal![e-mail] (Terry Ingoldsby)
Subject: Re: File tranfser of software--A way to curb commercial infections?

In article <[e-mail]>, [e-mail]
m (Gary Heston) writes:
> ctycal![e-mail] (Terry Ingoldsby) writes:
>
> > I've always felt that networks are less likely to transmit viruses
> > than floppy disks because it is more likely that the culprit will be
> > caught.  I grant that games can be played with the signatures, etc.,
> > but chances are that some sort of log files are kept by the system
> > administrators about what came in, and when.  Although difficult, in a
> > crisis there is at least some hope that the dissemination path used by
> > the virus can be discovered.  Although not foolproof, this should act
> > as somewhat of a deterrent to virus writers.
>
...
> Networks can propagate a virus thru several avenues, particularly if
> the netadmin is inexperienced and hasn't quite got file protections
> for network executables set correctly. If user Fred logs in to a

I freely concede this.  Networks are no safer than floppies.  You miss
the point.

> Now, we have a logfile that shows Fred, Barney, and 30 other users
> ran this particular piece of software, at various times during the
> day, and probably more than once. What points to the infection
> source?
Not *that* logfile.  I'm uninterested in who runs it on the (now)
infected system.  What I am trying to establish is the pattern of
transmission for the virus.  For instance, it is of interest to
know the general propogation path through the network.  This can
lead you back towards the site where the virus initially started.
Once you get to that site, then you can try to find the user who
owns the *source* code to the virus.  Since we do backups at
unpredictable times on our system, it would be tricky (but not
impossible) for a virus writer to hide the source code.
>
> This can be controlled somewhat by the netadmin getting the
> setup correct; however, this is a somewhat optomistic hope in
> view of the complexity of network software and the limited
> training new admins get (I'm trying to learn Novell right
> now; the company decided nobody needs to go to seminars for
> anything). It's difficult to track down a security hole when
> the boss is asking hourly "Why isn't the network up yet?".

Then your boss deserves what he gets.

> is necessary. Training admins to check EVERY piece of software
> prior to installation, no matter how many layers of plastic it
> was (or wasn't) wrapped in, along with safe setups. Teaching
> management that this really is necessary, not just a waste
> of resources, and you really do need that many tapes for
> backups. Etc.

Agreed.

>
> > Floppy disks are almost untraceable since they carry *no* copy history,
> > *no* history of what machines they visited and almost no means of
> > identifying the offender.
>
> True. However, the person holding it can explain why they were
> running the software without checking it....

Thereby punishing the victim rather than the perpetrator.  This is
somewhat like telling a rape victim that it was their fault for
walking down an alley at night.  It is true that they might be
considered foolish for doing so, but they are not the party that
should be held responsible for the offense.

My point is not that viruses are less able to infect systems via
networks than via floppy disks, but rather that the significant
possibility of getting caught (say 1 chance in 5 ??)  should
dissuade people who otherwise have no chance of getting caught.

Virus prevention has got to focus more on identifying the
culprits, and less on treating the symptoms if this is ever
going to occur.  Networks (perhaps better networks than what we
have today) are our best chance of finding violators.

Sorry to be so long-winded, but I feel that this is a philosophical
point that is often missed in comp.virus discussions.

- --
  Terry Ingoldsby                ctycal![e-mail]
  Land Information Services                 or
  The City of Calgary       ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb


------------------------------

Date:    Tue, 05 Jun 90 19:27:05 -0500
From:    [e-mail]
Subject: Re: How to reset CMOS configuration that prevents booting? (PC)

[e-mail] writes:
> I've managed to do something truly bizarre to my computer. :)
>
> I have a '386 motherboard with lots of Chips and Technologies stuff on
> it. At boot time, I have the option to run setup/extended setup. While
> trying to do something, I managed to alter the settings in 'extended
> setup' part (the bits in various 'C&T CMOS registers') in such a
> manner that the machine will no longer boot; when I reset it, it goes
> beep-beep-beep pause beep-beep-beep...
> ...
> Thanks,
> Dimitri Vulis

          The three beeps seem to indicate a memory error.  You may have
          done some unintentional mods to your memory configuration on the
          motherboard.  Any PC will not boot if it either finds an error in
          the first 16KB of RAM or cannot locate it as this is usually where
          it tries to load the startup BIOS.

          Regards Robert,
          (University of QLD)

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 106]
******************************************
VIRUS-L Digest   Tuesday,  5 Jun 1990    Volume 3 : Issue 107

Today's Topics:

Anti-viral archive sites, introduction
unix anti-viral sites
atari.st anti-viral sites
docs anti-viral sites
apple.ii anti-viral sites
mac anti-viral sites
amiga anti-viral sites
ibmpc anti-viral sites

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 01 Jun 90 09:43:45 -1000
From:    Jim Wright <[e-mail]>
Subject: Anti-viral archive sites, introduction

# Introduction to the Anti-viral archives...
# Listing of 03 May 1990

This posting is the introduction to the "official" anti-viral archives
of VIRUS-L/comp.virus.  With the generous cooperation of many sites
throughout the world, we are attempting to make available to all
the most recent news and programs for dealing with the virus problem.
Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh
and Unix computers, as well as sites carrying research papers and
reports of general interest.

If you have general questions regarding the archives, you can send
them to this list or to me.  I'll do my best to help.  If you have a
submission for the archives, you can send it to me or to one of the
persons in charge of the relevant sites.

If you have any corrections to the lists, please let me know.

The files contained on the participating archive sites are provided freely
on an as-is basis.

To the best of our knowledge, all files contained in the archives are either
Public Domain, Freely Redistributable, or Shareware.  If you know of one
that is not, please drop us a line and let us know.  Reports of corrupt
files are also welcome.

PLEASE NOTE
The Managers of these systems, and the Maintainers of the archives, CAN NOT
and DO NOT guarantee any of these applications for any purpose.  All possible
precautions have been taken to assure you of a safe repository of useful
tools.

STATUS OF THE VALIDATION LIST
I continue to offer to post a monthly validation list.  It will contain any
information the authors of anti-viral programs feel will be useful in
validating their programs to be untampered with.  The specific information
is left to each author, since no standard method yet exists.  For obvious
reasons, I will only accept information from authors or their designated
agent.  So far, no interest has been shown.  If do not see any interest in
the next month, I'll just forget about it.

Jim Wright
[e-mail]

------------------------------

Date:    Mon, 04 Jun 90 10:25:16 -1000
From:    Jim Wright <[e-mail]>
Subject: unix anti-viral sites

# Anti-viral and security archive sites for Unix
# Listing last changed 03 May 1990

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

funic.funet.fi
          Jyrki Kuoppala <[e-mail]>
          Accessible through anonymous ftp, IP number 128.214.6.100.
          Directory pub/unix/security contains programs to help in
          security, pub/doc/security contains various documents about
          security in general and unix security (like the worm
          documents)

ucf1vm
          Lois Buwalda <[e-mail]>
          Accessible through...

wuarchive.wustl.edu
          Chris Myers <[e-mail]>
          Accessible through anonymous ftp, IP number 128.252.135.4.
          A number of directories can be found in ~ftp/usenet/comp.virus/*.


------------------------------

Date:    Mon, 04 Jun 90 10:25:08 -1000
From:    Jim Wright <[e-mail]>
Subject: atari.st anti-viral sites

# Anti-viral archive sites for the Atari ST
# Listing last changed 30 September 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Atari ST index for the virus archives can be retrieved as
                    request: atari
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>.

panarthea.ebay
          Steve Grimm <[e-mail]>
          Access to the archives is through mail server.
          For instructions on the archiver server, send
                    help
          to <[e-mail]>.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for index.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.


------------------------------

Date:    Mon, 04 Jun 90 10:25:11 -1000
From:    Jim Wright <[e-mail]>
Subject: docs anti-viral sites

# Anti-viral archive sites for documentation
# Listing last changed 04 April 1990

cert.sei.cmu.edu
          Kenneth R. van Wyk <[e-mail]>
          Access is available via anonymous ftp, IP number 128.237.253.5.
          This site maintains archives of all VIRUS-L digests, all
          CERT advisories, as well as a number of informational documents.
          VIRUS-L/comp.virus information is in:
                    pub/virus-l/archives
                    pub/virus-l/archives/predig
                    pub/virus-l/archives/1988
                    pub/virus-l/archives/1989
                    pub/virus-l/archives/1990
                    pub/virus-l/docs
          CERT information is in:
                    pub/cert_advisories
                    pub/cert-tools_archive

csrc.ncsl.nist.gov
          John Wack <[e-mail]>
          This site is available via anonymous ftp, IP number 129.6.48.87.
          The archives contain all security bulletins issued thus far from
          organizations such as NIST, CERT, NASA-SPAN, DDN, and LLNL-CIAC.
          Also, other related security publications (from NIST and others)
          and a partial archive of VIRUS_L's and RISK forums.

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The index for the **GENERAL** virus archives can be retrieved as
                    request: general
                    topic: index
          The index for the **MISC.** virus archives can be retrieved as
                    request: misc
                    topic: index
          **VIRUS-L** entries are stored in monthly and weekly digest form from
          May 1988 to December 1988.  These are accessed as log.8804 where
          the topic substring is comprised of the year, month and a week
          letter.  The topics are:
                    8804, 8805, 8806 - monthly digests up to June 1988
                    8806a, 8806b, 8806c, 8806d, 8807a .. 8812d - weekly digests
          The following daily digest format started on Wed 9 Nov 1988.  Digests
          are stored by volume number, e.g.
                    request: virus
                    topic: v1.2
          would retrieve issue 2 of volume 1, in addition v1.index, v2.index and
          v1.contents, v2.contents will retrieve an index of available digests
          and a extracted list of the the contents of each volume respectively.
          **COMP.RISKS** archives from v7.96 are available on line as:
                    request: comp.risks
                    topic: v7.96
          where topic is the issue number, as above v7.index, v8.index and
          v7.contents and v8.contents will retrieve indexes and contents lists.
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

lehiibm1.bitnet
          Ken van Wyk <[e-mail]> new: <[e-mail]>
          This site has archives of VIRUS-L, and many papers of
          general interest.
          Access is through ftp, IP address 128.180.2.1.
          The directories of interest are VIRUS-L and VIRUS-P.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for index.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

unma.unm.edu
          Dave Grisham <[e-mail]>
          This site has a collection of ethics documents.
          Included are legislation from several states and policies
          from many institutions.
          Access is through ftp, IP address 129.24.8.1.
          Look in the directory /ethics.


------------------------------

Date:    Mon, 04 Jun 90 10:25:07 -1000
From:    Jim Wright <[e-mail]>
Subject: apple.ii anti-viral sites

# Anti-viral archive sites for the Apple II
# Listing last changed 30 September 1989

brownvm.bitnet
          Chris Chung <[e-mail]>
          Access is through LISTSERV, using SEND, TELL and MAIL commands.
          Files are stored as
                    apple2-l xx-xxxxx
          where the x's are the file number.

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Apple II index for the virus archives can be retrieved as
                    request: apple
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for index.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.


------------------------------

Date:    Mon, 04 Jun 90 10:25:15 -1000
From:    Jim Wright <[e-mail]>
Subject: mac anti-viral sites

# Anti-viral archive sites for the Macintosh
# Listing last changed 07 November 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Mac index for the virus archives can be retrieved as
                    request: mac
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

ifi.ethz.ch
          Danny Schwendener <[e-mail]>
          Interactive access through DECnet (SPAN/HEPnet):
                    $SET HOST 57434  or $SET HOST AEOLUS
                    Username: MAC
          Interactive access through X.25 (022847911065) or Modem 2400 bps
          ([phone]):
                    # CALL B050 <cr><cr>
                    Username: MAC
          Files may also be copied via DECnet (SPAN/HEPnet) from
                    57434::DISK8:[MAC.TOP.LIBRARY.VIRUS]

rascal.ics.utexas.edu
          Werner Uhrig <[e-mail]>
          Access is through anonymous ftp, IP number is 128.83.144.1.
          Archives can be found in the directory mac/virus-tools.
          Please retrieve the file 00.INDEX and review it offline.
          Due to the size of the archive, online browsing is discouraged.

scfvm.bitnet
          Joe McMahon <[e-mail]>
          Access is via LISTSERV.
          SCFVM offers an "automatic update" service.  Send the message
                    AFD ADD VIRUSREM PACKAGE
          and you will receive updates as the archive is updated.
          You can also subscribe to automatic file update information with
                    FUI ADD VIRUSREM PACKAGE

sumex-aim.stanford.edu
          Bill Lipa <[e-mail]>
          Access is through anonymous ftp, IP number is 36.44.0.6.
          Archives can be found in /info-mac/virus.
          Administrative queries to <[e-mail]>.
          Submissions to <[e-mail]>.
          There are a number of sites which maintain shadow archives of
          the info-mac archives at sumex:
          * MACSERV@PUCC                services the Bitnet community
          * LISTSERV@RICE               for e-mail users
          * FILESERV@IRLEARN  for folks in Europe

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for index.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

wsmr-simtel20.army.mil
          Robert Thum <[e-mail]>
          Access is through anonymous ftp, IP number 26.2.0.74.
          Archives can be found in PD3:<MACINTOSH.VIRUS>.
          Please get the file 00README.TXT and review it offline.


------------------------------

Date:    Mon, 04 Jun 90 10:25:07 -1000
From:    Jim Wright <[e-mail]>
Subject: amiga anti-viral sites

# Anti-viral archive sites for the Amiga
# Listing last changed 30 September 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Amiga index for the virus archives can be retrieved as
                    request: amiga
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

ms.uky.edu
          Sean Casey <[e-mail]>
          Access is through anonymous ftp.
          The Amiga anti-viral archives can be found in /pub/amiga/Antivirus.
          The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for index.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

uxe.cso.uiuc.edu
          Mark Zinzow <[e-mail]>
          Lionel Hummel <[e-mail]>
          The archives are in /amiga/virus.
          There is also a lot of stuff to be found in the Fish collection.
          The IP address is 128.174.5.54.
          Another possible source is uihub.cs.uiuc.edu at 128.174.252.27.
          Check there in /pub/amiga/virus.


------------------------------

Date:    Mon, 04 Jun 90 10:25:13 -1000
From:    Jim Wright <[e-mail]>
Subject: ibmpc anti-viral sites

# Anti-viral archive for the IBMPC
# Listing last changed 10 May 1990

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The IBMPC index for the virus archives can be retrieved as
                    request: ibmpc
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

f.ms.uky.edu
          Daniel Chaney <[e-mail]>
          This site can be reached through anonymous ftp.
          The IBMPC anti-viral archives can be found in /pub/msdos/AntiVirus.
          The IP address is 128.163.128.6.

mibsrv.mib.eng.ua.edu
          James Ford <[e-mail]> <[e-mail]>
          This site can be reached through anonymous ftp.
          The IBM-PC anti-virals can be found in PUB/IBM-ANTIVIRUS
          Uploads to PUB/IBM-ANTIVIRUS/00UPLOADS.  Uploads are screened.
          Requests to [e-mail] for UUENCODED files will be filled
          on a limited bases as time permits.
          The IP address is 130.160.20.80.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for index.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

ux1.cso.uiuc.edu
          Mark Zinzow <[e-mail]>
          This site can be reached through anonymous ftp.
          The IBMPC anti-viral archives are in /pc/virus.
          The IP address is 128.174.5.59.

vega.hut.fi
          Timo Kiravuo <[e-mail]>
          This site (in Finland) can be reached through anonymous ftp.
          The IBMPC anti-viral archives are in /pub/pc/virus.
          The IP address is 130.233.200.42.

wsmr-simtel20.army.mil
          Keith Peterson <[e-mail]>
          Direct access is through anonymous ftp, IP 26.2.0.74.
          The anti-viral archives are in PD1:<MSDOS.TROJAN-PRO>.
          Simtel is a TOPS-20 machine, and as such you should use
          "tenex" mode and not "binary" mode to retreive archives.
          Please get the file 00-INDEX.TXT using "ascii" mode and
          review it offline.
          NOTE:
          There are also a number of servers which provide access
          to the archives at simtel.
          WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands
          from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe
          from EARN TRICKLE servers.  Send commands to TRICKLE@<host-name>
          (for example: TRICKLE@AWIWUW11).  The following TRICKLE servers
          are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium),
          DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy),
          EB0UB011 (Spain) and TREARN (Turkey).


------------------------------

End of VIRUS-L Digest [Volume 3 Issue 107]
******************************************
VIRUS-L Digest   Wednesday,  6 Jun 1990    Volume 3 : Issue 108

Today's Topics:

Analysis of the KEYBGR / FACE problem (PC)
Re: intentional viruses and happy face (general and Mac)
Re: Mac Happy Face turns into a Devil... (Mac)
Stoned (PC)
Re: Removing Stoned from harddisks (PC)
Re: How to reset CMOS configuration that prevents booting? (PC)
Re: Mac Happy Face turns into a Devil... (Mac)
Search strings for IBM VIRSCAN program (PC)
How many Universities have a site-license for McAfee's programs (PC)
Possible virus (PC)
The Devil Made Me Do It
WARNING: Potential Trojan Horse 'STEROID' (Mac)
Gutowski Comments on Unix v. MVS et. al.
F*** Clone of nVir B (Mac)
Info wanted - European Computing Services Assoc.

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Tue, 05 Jun 90 16:14:39 -0500
From:    Christoph Fischer <[e-mail]>
Subject: Analysis of the KEYBGR / FACE problem (PC)

Hi
  over the weekend I analysed the KEYBGR.COM it is a hacked version of the
original KEYBGR.COM MSDOS V2.1. I asked Mr Joest to keep an eye on the
replacements (original) maybe they change again, this could possibly be a hint
that they have a trojan horse producing a trojan horse. (This is theory sofar
and they ran tests that turned out negative, so lets hope it stays that way)
Again as a result: it is *not* a virus! It is a trojan horse with transient
                   damage.

      Christoph Fischer

*****************************************************************
* Christoph Fischer                                             *
* Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
* D-7500 Karlsruhe 1, Zirkel 2, Tel.: [phone]       *
* E-Mail: RY15 at DKAUNI11.BITNET                               *
*****************************************************************

------------------------------

Date:    Tue, 05 Jun 90 11:43:33 -0400
From:    Joe McMahon <[e-mail]>
Subject: Re: intentional viruses and happy face (general and Mac)

>I have had just the strangest thought about all of the commercial
>products out there on the market that protect from viruses, for
>example Symantec's Anti-Virus for the Macintosh -- a product that
>"learns"...

Two points: Deterction is the best solution to viruses. Find them and
replace the programs if you want to be sure you're safe. Second, I
know where SAM's author lives :-). Seriously, you've got to trust
someone.  Especially that if someone got caught doing that, I'm sure
that there are plenty of existing laws they could be convicted under
(extortion?).

>Subject: Mac Happy Face turns into a Devil... (Mac)
>
>I just experimented with a public Mac which wasn't
>working too well. When I watched it boot up, the usual
>smiling Macintosh icon turned into a devil with horns,
>fangs and a long tail. I checked it with Disinfectant 1.8
>and found nothing.

Does the "Welcome to Macintosh" window appear afterward? If not,
someone's probably put a startup screen in the System Folder. I just
tried this - I got my Mac to stick out its tongue at me :-).

 --- Joe M.

------------------------------

Date:    05 Jun 90 16:19:10 +0000
From:    nikhefk![e-mail] (Kees Huyser)
Subject: Re: Mac Happy Face turns into a Devil... (Mac)

[e-mail] (Pete) writes:
#I just experimented with a public Mac which wasn't
#working too well. When I watched it boot up, the usual
#smiling Macintosh icon turned into a devil with horns,
#fangs and a long tail. I checked it with Disinfectant 1.8
#and found nothing.
#
#My questions are:
#
#1) Is this a virus or is it some legitimate program I've
#never experienced before?
#
#Peter Wayner   Department of Computer Science Cornell Univ. Ithaca, NY 14850
#EMail:[e-mail]    Office: 607-255-9202 or 255-1008
#Home: 116 Oak Ave, Ithaca, NY 14850  Phone: [phone]

Take a look in the System Folder on this Mac. If you find a file called
StartUpScreen, take a look at it with MacPaint. This will probably show you
the devil in all its glory...

If you don't find StartUpScreen, *or* if it doesn't contain a devil you might
be in trouble.....

- --kees
/* -------------------------------------------------------------------- */
/* [e-mail] or {..!uunet.uu.net}!mcsun!hp4nl!nikhefk!keeshu */
/* The National Institute for Nuclear Physics and High-Energy Physics */
/* P.O.Box 4395, 1009 AJ Amsterdam, The Netherlands, phone:[phone] */
/* -------------------------------------------------------------------- */

------------------------------

Date:    Tue, 05 Jun 90 10:44:06 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: Stoned (PC)

>During the last two months there were several asks how to remove
>the STONED-virus from harddisks. The solution is quite easy :

In previous issues, I have seen a number of postings on the STONED
virus reguarding disinfecting disks. One thing that is often missed is
that three separate methods seem necessary:

a) floppy disks
b) un-partitioned hard disks
c) partitioned hard disks

It is not well documented but on boot up with a partitioned disk there
is executable code in the partition table that tells DOS where to find
the boot record for the first partition and that the STONED is
reported to be able to infect this (I have a copy but have not had the
time to check it out). DEBUG cannot read/modify the partition table so
some of the methods presented thusfar will not necessarily work on
such a disk.

I suspect that the STONED simply replaces the first physical sector (DEBUG
uses logical sectors) and does not care whether it contains the boot sector
or the partition table and stores the original sector in physical sector 7.

               Padgett Peterson

------------------------------

Date:    Tue, 05 Jun 90 19:35:11 -0500
From:    "Zoltan DAROCZI (8350893)" <[e-mail]>
Subject: Re: Removing Stoned from harddisks (PC)

Martin Zejma ( 8326442-awiwuw11.bitnet) writes:
>4) write this sector over the infected boot sector of the harddisk.
>   ( that's Head 0 , Track 0 , Sector 0 , just to make it failsafe).

the sectornumbers on harddisks are starting at 1, not at 0 ||
so the right position is Head 0 , Track 0 , Sector 0.
at 3) the sectornumber is correct.

------------------------------

Date:    05 Jun 90 17:49:46 +0000
From:    [e-mail] (Bruce Benson)
Subject: Re: How to reset CMOS configuration that prevents booting? (PC)

[e-mail] writes:
>> manner that the machine will no longer boot; when I reset it, it goes
>> beep-beep-beep pause beep-beep-beep...
>
>         The three beeps seem to indicate a memory error.  You may have
>         done some unintentional mods to your memory configuration on the
>         motherboard.  Any PC will not boot if it either finds an error in
>         the first 16KB of RAM or cannot locate it as this is usually where
>         it tries to load the startup BIOS.

Just within the last 5 days my Zeos 386 w/AMI Bios has started this same
pattern of three beeps.  The AMI documentation says this means an error
in the first 64K. A few other facts:

  - seems to happen when I first boot the machine after being off many hours
  - repeated cold boots eventually resulted in a successful boot
  - replacing all simms (4mb) had no affect on the problem (but I do
    now have a total of 8Mb of memory, good excuse to buy!)
  - using the hardware reset switch clears the problem immediately
  - the only system changes in this period was to add an internal MNP modem

I am still playing with the problem, but anyone with more insight into the
meaning of the 3 beeps, or why the reset switch would work differently than
power on/off, please offer up your insights.

* Bruce Benson                   + Internet  - [e-mail] +       +
* Software Engineering Institute + Compuserv - 76226,3407      +    >--|>
* Carnegie Mellon University     + Voice     - 412 268 8496    +       +
* Pittsburgh PA 15213-3890       +                             +  US Air Force

------------------------------

Date:    05 Jun 90 17:54:38 +0000
From:    [e-mail] (Richard Clark)
Subject: Re: Mac Happy Face turns into a Devil... (Mac)

The "Fanged Happy Face" is a deliberate side effect of installing the Levco
"Monster Mac" RAM upgrade (and an accelerator, I think.)

- -----------------------------+-----------------------------------------------
Richard Clark                | "If you don't know where you're going,
Instructor/Designer          |  don't go there" -- Sybalski's Law
Apple Developer University   +-----------------------------------------------
AppleLink, GEnie, Delphi, MCI, Internet: rdclark  CI$: 71401, 2071

------------------------------

Date:    Tue, 05 Jun 90 14:35:48 -0400
From:    Ken Rosenberry <[e-mail]>
Subject: Search strings for IBM VIRSCAN program (PC)

The VIRSCAN.EXE program from IBM uses two signature files as input when
performing a virus scan.  These files are:

    SIGFILE.LST   - a list of signature entries for EXE and COM files
    SIGBOOT.LST   - a list of signature entries for boot sectors

We have versions of these files dated Sept 11, 1989.  Are there any
persons who maintain updated versions of these files as new viruses are
discovered?  If so, could you please either E-mail me the new files or
post info on where they could be obtained.

Thank you

Ken Rosenberry                    BITNET:    hkr@psuvm
Senior Systems Programmer         Internet:  [e-mail]
Pennsylvania State University     APPLELINK: u0485

------------------------------

Date:    Tue, 05 Jun 90 14:55:39 -0400
From:    Ken Rosenberry <[e-mail]>
Subject: How many Universities have a site-license for McAfee's programs (PC)

Various organizations within our University are attempting to
negotiate a site license for John McAfee's virus scan and clean
programs.  We are finding that the cost for the programs is VERY high
($18,000 per year).  That is a significant portion of our computing
center's software budget for new acquisitions.

I'd like to know what other institutions are paying for the rights to
use this software.  Please E-mail your responses directly to me; I
will keep the information confidential.

Thank you.

Ken Rosenberry                    BITNET:    hkr@psuvm
Senior Systems Programmer         Internet:  [e-mail]
Pennsylvania State University     APPLELINK: u0485

------------------------------

Date:    Tue, 05 Jun 90 16:24:00 -0500
From:    SEAN KRULEWITCH <[e-mail]>
Subject: Possible virus (PC)

To Who it may concern:

I am fairly new to the whole idea of viruses and the like.  I recently
purchased an IBM clone (AMI motherboard 386-20) and have experienced a
few unusual things.  Files seem to be vanishing off the disk, and
other programs are acting weird.  For example when I run Windows386 I
get a KERNSTUB error during boot, and I am sent back to the dos
prompt.  When I try again, I get an incorrect Dos version error.  If I
then proceed to type ver it says Dos 3.41.  However I am running Dos
4.01.  If i type ver a few more times it continues to say dos 3.41.
After the third or fourth time it goes back to saying Dos 4.01.  Also
Procomm locks up when I try to enter the setup mode (ALT-S) and I am
forced to turn the machine off (Warm boot doesn't work).  After a
while the whole system seems to slow down considerably.  One symptom
that seems to be common is a small section of the lower left hand side
of the screen seems to shift up, leaving a small "hole".  This happens
in various programs and at the dos prompt.  I thought it may be a
problem with my video card, but the card checks out ok.  Certain
programs that worked before no longer work.  If anyone knows what this
may be, please contact me.  I can be reached at the following
addresses:

                       [e-mail] or
                       [e-mail]

                                        Sincerely,
                                        Sean V. Krulewitch

------------------------------

Date:    Tue, 05 Jun 90 17:50:42 -0400
From:    [e-mail] (Pete)
Subject: The Devil Made Me Do It

Thanks to the help of several people on the net, I've discovered that
it is quite easy to make the Happy Mac Screen turn into anything you
please. Just include a startupscreen file in the system folder. This
is exactly what a clever person did. SuperPaint lets you create these
automatically.

I would think it was rather clever if I hadn't spent the day wringing
my hands. The worst casualty of the virus epidemic may not be lost
data, but our senses of humor.

- --
Peter Wayner   Department of Computer Science Cornell Univ. Ithaca, NY 14850
EMail:[e-mail]    Office: 607-255-9202 or 255-1008
Home: 116 Oak Ave, Ithaca, NY 14850  Phone: [phone]

------------------------------

Date:    05 Jun 90 21:55:00 +0000
From:    [e-mail] (That's MR. Idiot to you)
Subject: WARNING: Potential Trojan Horse 'STEROID' (Mac)

I have just been warned by some people here at Apple that a new Trojan
Horse has been discovered. The INIT 'STEROID', which supposedly speeds
up QuickDraw on a 9" monitor, has a time bomb in it that will cause it
to erase any mounted volumes when it is booted after June 6, 1990
(that's Wednesday). The program has been disassembled here at Apple
and the actions have been confirmed.

IF YOU HAVE STEROID ON YOUR SYSTEM, DISABLE IT IMMEDIATELY.

The details: Type INIT, Creator qdac, Code size 1080, data size 267,
          File Name "  Steroid", name "Quickdraw Accelerator"

More data when I have it.

chuq

Chuq Von Rospach   <+>   [e-mail]   <+>   [This is myself speaking]

It isn't easy being green.              -- Kermit

------------------------------

Date:    Wed, 06 Jun 90 07:45:00 -0400
From:    [e-mail]
Subject: Gutowski Comments on Unix v. MVS et. al.

>Again, it is just a matter of choice.  Unix was intended to be a programmer's
>system; as such it does a great job.  With all systems, there is a tradeoff
>between functionality and security, the trick is to find the right
>balance.

True.  But it also makes the point of what happens when systems
outgrow, or simply outlast, their intended application and
environment.  The Unix problem is complicated by the fact that it
carries with it styles of use and management that were appropriate for
stand-alone support of small homogenous user populations, but which
are disastrous when employed in networked systems with large
heterogenuous populations.  (I will spare you a re-cap of "The
Cuckoo's Egg.")

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    Wed, 06 Jun 90 08:04:00 -0400
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: F*** Clone of nVir B (Mac)

Can someone tell me about what date the "Fuck" clone appeared?  Thanks.

                                                Greg.
Postal address: Gregory E. Gilbert
                Computer Services Division
                University of South Carolina
                Columbia, South Carolina   USA   29208
                [phone]

------------------------------

Date:    Wed, 06 Jun 90 15:33:22 +0500
From:    AHMET KOLTUKSUZ <[e-mail]>
Subject: Info wanted - European Computing Services Assoc.

      Hello Folks;

    Does anyone know anything about the EUROPEAN COMPUTING SERVICES
    ASSOCIATION .. like its address or anyone there whom I could
    possibly get in contact with ? or anything..
    All helps will be appreciated deeply.. Thank you
    I hear that those folks are interested in computer laws
    against computer abuse or something...

    Please acknowledge to: <[e-mail]>

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 108]
******************************************
VIRUS-L Digest   Thursday,  7 Jun 1990    Volume 3 : Issue 109

Today's Topics:

Steriod Trojan -- WARNING! (Mac)
re: Stoned (PC)
Search strings for IBM VIRSCAN program (PC)
re: Possible virus (PC)
Re: clearing ps/2 pw, faces on screen (PC)
"validate" program for Macs
MDEF anyone? (Mac)
Steroid Trojan and SAM 2.0 (Mac)
Re: Intentional Virus(es?)
MAC Trojan announcement

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 06 Jun 90 09:19:51 -0400
From:    Tom Coradeschi <[e-mail]>
Subject: Steriod Trojan -- WARNING! (Mac)

This was posted today to Info-Mac.

tom c

                           = Every Day is Earth Day =
          ARPA: [e-mail]     BITNET: [e-mail]
                UUCP: ...!{uunet,rutgers}!pica.army.mil!tcora

- ----- Forwarded message # 1:

Date: Tue, 5 Jun 90 15:07:26 -0700
From: William Lipa <[e-mail]>
Subject: Steriod Trojan -- WARNING!

Steroid Trojan Horse

There is a Trojan Horse called "Steroid".  It is an INIT that claims to speed
up QuickDraw on Macintosh computers with 9" screens.  The INIT contains code
that checks for the date being greater than June 6,1990.  If it is, it will
ERASE all mounted drives.

I have performed some tests on a Macintosh SE.  Having Comm Toolbox installed
seemed to interfere with the INIT and keep the erase from happening.  The SE
simply crashed.

I then installed the INIT on a floppy disk and booted the SE.  The floppy and
hard disk were promply erased.  NOTE: I had set the date to 7/7/90.

So far, we know that the code does the following:

OPERATIONS AT RESTART:

 DATE & TIME CHECK (Loop)
 SYSENVIRONS CHECK
 GETS VOLUME INFORMATION (probably checking for HFS)
 GETS SOME ADRESSES (Toolbox traps)
 DOES SOME HFS DISPATCH OPERATIONS
 VOLUME IS REINITIALIZED to "Untitled"

INFORMATION:
- ------------
TYPE:      INIT
CREATOR:   qdac
CODE SIZE: 1080
DATA SIZE: 267
ID:        148
Name:      QuickDraw Accelorator
File Name: "  Steroid" (First 2 characters are ASCII 1)

WHAT TO DO:
- -----------
If your disk becomes erased, you can use SUM II Disk Clinic to recover the
deleted files.  We have tried this and it seems to work.  If you read this
today, before June 6 1990, REMOVE the Steroid INIT from all disks IMMEDIATELY.

POSTED BY:

Thomas Scott
Desktop Services
AppleLink: MICRO.SUPT

Thanks to Larry Nedry, Lee Neuse, & Gary Giusti for information

- ----- End of forwarded messages

------------------------------

Date:    06 Jun 90 09:41:01 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: re: Stoned (PC)

Yep, the Stoned installs itself on the bottommost sector of the
physical disk, which is the place where the partition table lives on a
partitioned hard disk.

>                        DEBUG cannot read/modify the partition table so
> some of the methods presented thusfar will not necessarily work on
> such a disk.

That's only sort of true; the DEBUG "load" command can only
see within the DOS partition, and therefore it can't see the
bottommost sector; but I think people were suggesting using
DEBUG to type in the tiny program needed to do the work.
For instance, if you go into debug and type

a 100
xor ax,ax
int 13
mov ax,0201
mov bx,0200
mov cx,0001
mov dx,0080
int 13
<enter by itself>
g 112
d 200 3ff

you'll be able to see the bottommost sector of the first hard disk,
including the partition table and the master boot code, sitting there
at address 200.  (Only do this if you have some idea of what you're
doing, of course!  The wrong typo in the above could easily make your
hard disk inaccessible.)  Similar tiny programs can read the original
stashed bottommost sector on a Stoned-infected hard disk, and write it
back to where it belongs.  I think that's what some folks were
suggesting...

DC

------------------------------

Date:    06 Jun 90 09:50:49 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: Search strings for IBM VIRSCAN program (PC)

> We have versions of these files dated Sept 11, 1989.  Are there any
> persons who maintain updated versions of these files as new viruses are
> discovered?

A new version of the scanning program, including new search strings,
was released the other month; ask your IBM marketing rep, or local
branch office, about the IBM Virus Scanning Program version 1.1.  (If
they can't find the information about it, give them my name; it's sort
of an unusual product...)

DC

------------------------------

Date:    06 Jun 90 09:53:28 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: re: Possible virus (PC)

SEAN KRULEWITCH <[e-mail]>:
> One symptom
> that seems to be common is a small section of the lower left hand side
> of the screen seems to shift up, leaving a small "hole".

That's a common symptom of the 1813 (or "Jerusalem") virus, one of the
most common PC-DOS viruses.  Have you used a virus-scanner on your
system?  If you *do* have an 1813 infection, the other symptoms that
you're seeing are probably due to various bugs in the virus and/or
"incompatibilities" between the virus and your various programs...

DC

------------------------------

Date:    06 Jun 90 14:02:33 +0000
From:    [e-mail] (Mike Cummings )
Subject: Re: clearing ps/2 pw, faces on screen (PC)

[e-mail] (The.Gar) writes:
>Dimitri -
>    I can't help you with your problem, other than to tell you that
>IBM's recommended procedure for a forgotten password USED TO BE to
>remove the battery from the motherboard (I had an original PS/2 70.)
>THIS HAS CHANGED, however, and they now have a "trick" that let's you
>quickly clear the password.  What one is now able to do, is unplug the
>speaker connector from the bus adapter card, and plug it in in the

          It seems to me that this is also a new way to compromise the
security of IBM equipment.  A better, more secure method of dealing
with the problem (ie. not a "trick") should be found and implemented.

- ---->  [e-mail]

------------------------------

Date:    Wed, 06 Jun 90 11:30:33 -0500
From:    [e-mail] (Emily H. Lonsford)
Subject: "validate" program for Macs

Does anyone know of a "validate" - type program for the Macintosh?
I'm looking for something similar to McAfee's VALIDATE program, which
is used to generate two checksums on a file, with independent
algorithms.  Thus when the file is transmitted, the checksums
generated before transmission are compared to the ones obtained after
transmission, to ensure that what is sent is received uncorrupted.

Thanks in advance for the help.
*        Emily H. Lonsford
*        MITRE - Houston W123  [phone]

------------------------------

Date:    Wed, 06 Jun 90 10:30:59 -0600
From:    "McMahon,Brian D" <[e-mail]>
Subject: MDEF anyone? (Mac)

Since the initial report, there's been a conspicuous LACK of any reports of
MDEF/Garfield hits.  Have they just not made it to the list?  Has Garfield
been contained?  Is it spreading undetected?  Inquiring minds want to know.

;-)

I posted a query to the Virus SIG in the Mac Utilities area of America
Online, and got this:

>Subj:  MDEF Marching Through Georgia?        90-06-04 19:50:27 EDT
>From:  DavidIIci
>
>    Brian,
>
>     While perusing through postings on the Mac Software BBS on PRODIGY, I
>came across a post from an individual in Douglasville, Georgia (a suburb to
>the west of Atlanta) who confirmed that he had been victimized by MDEF. It
>had been found on a disk that he'd brought back from a local service
>bureau. He'd taken a Quark XPress job there to be run out. When he
>returned, a scan from a virus detection program (think it was Disinfectant)
>confirmed a viral infection.....MDEF.
[ Stuff deleted ]

If this (third-hand) report is accurate, then the thing is on its merry
way.  If anyone has further info, please consider contacting me directly.
Indulge me in my little quirk...  :-)

Brian McMahon  <[e-mail]> | VAX Kludgemeister, Macintosh Medic,
Grinnell College Computer Services    | Human Help Key, various and sundry
Grinnell, Iowa 50112                  | stats packages.  Please allow two
[phone]                        | to four weeks for miracles.
(No, *NOT* Idaho!  Not Ohio, either!)

------------------------------

Date:    06 Jun 90 16:20:00 +0000
From:    [e-mail] (SoftPlus, Paul Cozza,PRT)
Subject: Steroid Trojan and SAM 2.0 (Mac)

For SAM 2.0 users:

As recently reported, a new Trojan horse named Steroid has recently
been discovered. It is set to go off on July 1st, 1990, at which time
it zeroes your volume directories (it is possible to recover files on
hard disks with utilities such as SUM II). Before that time the Trojan
remains dormant.

This Trojan is shipped with the file name (Steroid) preceded by 2
invisible characters along with a warning not to change the file name.
These 2 invisible characters are there to make it load before SAM (or
other INITs). If you leave this file in your system folder, then you
are in danger (especially if have not renamed it).

If you have renamed the file so that it runs after SAM (in general, NO
unknown INITs should ever be allowed to run before SAM), then in
advanced or custom modes you will get SAM alerts saying "There is an
attempt to bypass the file system" when this Trojan attacks your
volumes. Denying these attempts prevents the Trojan from doing any
damage.

You can enter the following virus definition in Virus Clinic to allow
both SAM Intercept and Virus Clinic to detect this Trojan during
scans.

   Virus Name:  Steroid Trojan
Resource Type:  INIT
  Resource ID:  148
Resource Size:  1080
Search String:  ADE9 343C 000A 4EFA FFF2 4A78    (hexadecimal)
String Offset:  96

If you have entered this definition and have renamed the Trojan to run
after SAM, then SAM Intercept will also notify you when this INIT is
run at startup time.

Paul Cozza
SAM Author

------------------------------

Date:    06 Jun 90 17:03:52 +0000
From:    [e-mail] (Richard W West)
Subject: Re: Intentional Virus(es?)

- -From: Peter Jaspers-Fayer <[e-mail]>
- -
- -Hmm, and do you also imagine that while the dentist is in there with
- -the drill that (just maybe) some extra bits of enamel may get
- -chipped off a nearby tooth, so that you'll get another cavity andd
- -have to come back sooner?  I guess there has to be some trust
- -someplace.

Yes, that is true, there has to be some trust someplace, but too much is
a bad thing.

- -From [e-mail] Wed Jun  6 10:46:02 1990
- -
- -You're not the first person to think that maybe it's the commercial
 anti-virus
- -programmers who are writing viruses. In fact, you're wrong. Also, don't you
- -think it's judgemental to single out a product like SAM and suggest a
- -malicious motive lurks behind its development and distribution?
- -

- -The facts are:
- -1) The SAM author has never written a virus;
- -
- -2) The author spends a huge amount of time and energy making the product as
- -   powerful as possible for the benefit of SAM's users;
- -
- -3) The author would be making his living on other software if there weren't a
- -   need for SAM. Contrary to your thought, many people consider his effort a
- -   service to the Mac community, not a scheme to bilk the Mac users!
- -
- -4) SAM 2.0 was upgraded to allow SAM users to get better defense against new
- -   viruses at no cost. Once the virus definition is entered by the user,
 there
- -   is next to no chance of becoming infected even unknowingly.  And the
 proper
- -   virus definition is posted usually within a day of the discovery of a new
- -   virus. All registered SAM users are send a postcard with the proper virus
- -   definition free of charge. Symantec has even stopped its subscription
- -   service since there is no need for it.
- -
- -5) It is somewhat true that upgrading SAM for virus removal requires a modest
- -   $15 fee. BUT, this simply covers Symantec costs. It was judged too
- -   dangerous for the user to enter his own repair information, and posting a
- -   program that would update SAM with the repair information could lead to
- -   someone using the program for a Trojan Horse. Hence, the decision was made
- -   to distribute SAM 2.0 as you now see it.  In the future, something even
- -   better will be done...
- -
- -In short, the SAM author has nothing to gain from writing a virus, and also
- -does not have the time, energy, or motivation to write a virus.
- -
- -Rich, I am an honest person, trying to make an honest living. And from my
- -contact with the other anti-virus authors, I don't suspect that any of them
- -would do what you suggest either.
- -
- -Paul Cozza
- -Author of SAM

I apologize for singling out SAM in that way, but I was aiming the
article at the entire market, not just the single product.  SAM was an
example, it was not to be portrayed as a criminal.

I had only realized that a great amount of trust is being put in the
hands of large corporations, and the two words "trust" and "large
corporation" do not commonly appear in the same sentence.  I am not
trying to say that we should not trust Symantec or any other such
company, I am saying, though, that we, as consumers, should not put
our entire trust in any large corporation, no matter how good the
cause.  I pointed out a rather large blind spot in the consumer mind.

You mention that you are an "honest person, trying to make an honest
living," and I truly believe you, but can you say that about everyone
within the Symantec Corporation?  What I am trying to say is that
there is always someone out there who will think of another way of
making another dollar.  It may not be within the Symantec corporation,
but there are other companies out there, and there are many people
working for each of those companies.  It would be very incorrect to
say that each of those employees, at least the higher-ups in the
companies, would never consider or try implementing such an idea.

Just as a side note, I am a proud owner of Symantec's Anti-Virus for
the Macintosh, and I have been testing it for building-wide
implementation/ installation here at Siemens.  I personally feel that
SAM is the best virus protection utility out there on the market to
date.

- -Rich West
Siemens Corporate Research and Development Labs
Princeton, New Jersey
Internet: [e-mail]

------------------------------

Date:    06 Jun 90 19:24:37 +0000
From:    [e-mail] (WiseGuy)
Subject: MAC Trojan announcement

I have seen two or three different announcements of the newest
possible MAC Trojan.  The firs two messages said the Trojan trigger
date would be today, Jun 6, 1990.  The last message, from the SAM
author, says the trigger date is July 1st.  Could someone please
clarify the discrepancy......

*^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^*
*   Dave Weissman - Goddard Space Flight Center - Code 543.0                *
*   X.400 - (C:USA,ADMD:TELEMAIL,PRMD:GSFC,O:GSFCMAIL,SN:WEISSMAN,FN:DAVID  *
*   INTERNET - [e-mail]  BITNET - dweissman@dftbit    *
*    ____      ____    _____________    __________   _____________          *
*   |    \    |    |  |             |  |          | |             |         *
*   |      \  |    |  |     ///|    |  |   ///////  |     ///|    |         *
*   |        \|    |  |    |___|    |  |  |_______  |    |___|    |         *
*   |    |\        |  |             |  |          | |             |         *
*   |    |  \      |  |     ///     |   ///////|  | |     ///     |         *
*   |    |    \    |  |    |   |    |   _______|  | |    |   |    |         *
*   |    |    |    |  |    |   |    |  |          | |    |   |    |         *
*    ////      ////    ////     ////    //////////   ////     ////          *
*^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^*

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 109]
******************************************VIRUS-L Digest   Friday,  8 Jun 1990    Volume 3 : Issue 110

Today's Topics:

Stone virus & Scan 3.1v59 (PC)
Re: removing Stoned from harddisks (PC)
Zipped packages, lzexe, and viruses
Possible virus or trojan (Mac)? Help!!!
Mainframe Viruses (Gutowski)
Creation of New Viruses to Sell Product
VIREX upgrade (Mac)
Re: VIRUS-L Digest V3 #109
New virus (PC)
Wanted - MDEF configuration for SAM (Mac)
Brain (PC)
Steroid trojan query (Mac)
First jailed UK computer hacker
1451COM / 1411EXE ? new virus (PC) ?
Samsung S800 diagnostics

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 06 Jun 90 22:08:00 -0400
From:    [e-mail]
Subject: Stone virus & Scan 3.1v59 (PC)

Hello,

Two queries:

        1. Could someone inform me of the symptoms of the
        STONE virus?

        2. I intent to install AcAfee's SCAN 3.1v59 on my
        computer. Will this do a good job of detecting
        possible virus infection or is there a more recent
        update of the program? Any comments are welcome.

You can answer me personally or through the list if you feel
that the information can benefit other people. Thanks in advance.

        Bogdan KARASEK

        [e-mail]

------------------------------

Date:    07 Jun 90 07:16:23 +0000
From:    plains![e-mail] (Brett G. Person)
Subject: Re: removing Stoned from harddisks (PC)

I had a friend call me who told me that Stoned actually damaged the
media on the hard drive.  He said they lost a full ten Meg. He took
the drive through a low-level + dos format, and only wound up with
20Meg on a 30 meg disk.

Now, I know that a piece of software isn't supposed to physically
destroy media, but he said that the tech from the disk company claimed
that Stoned actually does destroy the media permanantly.  I don't
pretend to know everything about the pc, do I told him I'd ask here.
My bet is that the drive was either mis-labled as a 30 meg, or somehow
partitioned wrong.

- --
Brett G. Person
North Dakota State University
uunet!plains!person | [e-mail] | [e-mail]

------------------------------

Date:    Thu, 07 Jun 90 10:33:47 +0000
From:    [e-mail] (Timo Salmi LASK)
Subject: Zipped packages, lzexe, and viruses

Thu 7-Jun-90: Lzexed files pose a problem for the present virus
scanners.  While waiting to see the announced scanv63 to appear with
abilities to scan lzexe-compressed files, I wrote a batch to handle
scanning .zip packages.  This bacth checks both ordinary and lzexed
files within a .zip package.  The following shareware and PD
programs are needed: pkunzip.exe, scan.exe, islzexe.exe,
unlzexe.exe, The packages containing these programs can be found
from good BBSes and eg from chyde.uwasa.fi by anonymous ftp.  The
new batch scanzip.bat is included in the updated /pc/ts/tsbat20.arc
batch file collection.  Available by anonymous ftp from
chyde.uwasa.fi, Vaasa, Finland, in the usual manner.

...................................................................
Prof. Timo Salmi        (Moderating at anon. ftp site 128.214.12.3)
School of Business Studies, University of Vaasa, SF-65101, Finland
Internet: [e-mail] Funet: gado::salmi Bitnet: salmi@finfun

------------------------------

Date:    06 Jun 90 19:22:42 +0000
From:    [e-mail]
Subject: Possible virus or trojan (Mac)? Help!!!

     I've got a strange Mac problem and need help.  Monday night, one
  of my colleagues allowed a friend in to the office to steal Mac software
  (using his old Mac disks, of course).  After the appropriate cussing-out
  and running-off, the machine in question (Mac SE, 20Mb hard disk, System
  6.0.3) started acting funny.  Symptoms:

       a.  We can't find any virii on it with Disinfectant 1.6 or 1.8
       b.  Suddenly icons can't find their applications
       c.  Applications are increasingly unable to open data files or
           find them
       d.  The parameters of applications like Versaterm are unaccountably
           changing themselves i.e. the baud rate changes itself or the
           Kermit parameters change for no known reason
       e.  The options of the System and Desktop are unaccountably changing
           themselves i.e. the sound bar is turned up without anyone having
           done it.
       f.  There are more system bombs, and other disk and ram error messages
           than I've ever seen before in two years of working with Macs.

      We're to the point now of chucking months worth of data and reformating
  the hard disk and starting over.  Any suggestions?  Any help?
  Anybody seen anything like this before?

       Mike Mitchell
       Institute of Molecular Design
       Department of Chemistry
       University of Houston
       (713)-749-4229
       [e-mail]

------------------------------

Date:    Wed, 06 Jun 90 16:20:00 -0400
From:    [e-mail]
Subject: Mainframe Viruses (Gutowski)

>I disagree with your premise about Unix vs. VM or MVS security, though.
>MVS has been in development far longer than Unix has been alive (even
>back beyond the days of MVT)....

I would not want to get into an argument about it, but the difference in
age is not signigficant.  Unix is much older than you might guess.

>.... and there are many shops that use MVS and VM >(IBM ain't making
>it on PS/2s alone).

Total licenses for MVS and VM are measured in the low tens of thousands.

>Thus, these operating systems have
>had much more opportunity for people to poke around in them.

I doubt that this is true in terms of years or hours.  It is likely true
in terms of determination and other resources.  Total reported integrity
flaws in MVS have likely been in the high tens.  Almost none were detected
or exploited by hackers.  Most were detected by people with special
knowledge and training after the expenditure of significant resources.

>Not to say they are invincible, mind you, but I think they're less
>susceptible than Unix.

Your confidence is poorly placed.  While MVS and VM are as secure as
IBM knows how to make them collectively, individual installations or
instances are likely no better than instances of Unix.  People who do
penetration studies of MVS and VM for a living report that eighty-five
percent will yield privilege to a knowledgeable attacker in hours to days.
Most will yield to a determined attacker in days, and less than one percent
will stand up for weeks.

This has little to do with design or implementation by IBM but with use
and management by their customers.  Most MVS and VM installations are
guilty of exactly the same kinds of problems as are reported in the
"Cuckoo's Egg."  The book takes its name from the attack that exploits the
gnu-emacs editor that runs privileged.  MVS installations are rife with
very general utilities that run privileged and have poor controls.

All of this has little to do with their vulnerability to viruses.  As
Dave Chess of IBM Research has tried to explain on this list several
times, viruses exploit the privileges of users rather than flaws in the
environment.  Operating system integrity and access controls will only
slow them.  If users have the privilege to execute an arbitrary program
of their own choice, can create or modify a procedure, and share data
with a sufficiently large population of peers, then that is all that is
required for the success of a virus.

The trick to the success of a virus is not in its code, but in how you get
it executed!

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    Wed, 06 Jun 90 16:22:00 -0400
From:    [e-mail]
Subject: Creation of New Viruses to Sell Product

>This leaves a greater potential for companies to profit from the
>creation of new viruses.

New viruses do not sell product.  Old viruses sell product.  There
are not enough copies of a new virus to be noticed.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date:    Thu, 07 Jun 90 13:56:00 -0400
From:    "Melissa Jehnings" <[e-mail]>
Subject: VIREX upgrade (Mac)

Has anyone heard when the new upgrade of VIREX was shipped?  I work at
an academic computing center who is registered with the VIREX upgrade
program and as of 07-June-1990, we have not yet received the newest
version, which checks for MDEF.  Any help would be greatly
appreciated.

Melissa Jehnings
Wheaton College
Norton, MA 02766
BITNET: JEHNINGS@WHEATNMA

------------------------------

Date:    Thu, 07 Jun 90 15:04:39 -0400
From:    Valdis Kletnieks <[e-mail]>
Subject: Re: VIRUS-L Digest V3 #109

>[e-mail] (The.Gar) writes:
>
>   It seems to me that this is also a new way to compromise the
>security of IBM equipment.  A better, more secure method of dealing
>with the problem (ie. not a "trick") should be found and implemented.

I will overlook the fact that in order to reverse the speaker wires etc,
it looks to me that you have to physically open the case.  At this point,
what's to stop the person from whatever he feels like?

"Security" doesn't mean much when the guy has already opened the box up
and is able to physically abuse the silicon.  You got a hard disk?  He can
REPLACE it with a (almost identical, but infected) copy.  You got a hardware
security module?  That can be ripped out.  And so on...

What is making the guy wait 20 mins buying you security-wise?  Do you have
a security guard who walks by every 15 minutes?  If so, you're probably a
site that has heavy duty security - why is an unknown person walking around
unescorted?  And if there's NOT a security guard walking by every 15
minutes, then most likely if the guy has enough time to rip it open, he
won't be bothered during a further 20 minute wait.

                                   Valdis Kletnieks
                                   Computer Systems Engineer
                                   Virginia Tech

------------------------------

Date:    Mon, 04 Jun 90 23:20:23 +0300
From:    Yuval Tal <[e-mail]>
Subject: New virus (PC)

I've just received a copy of a virus called "Armagedon the GREEK".
Have anyone ever seen this virus? SCAN 62 did not identify this virus
so I consider this as a new virus. I've checked it a bit and from what
I found out, at a certain time, the virus sends a special command to
your ports which a Hayes compatible modem can understand!

Greek fellows: What does the phone number 081-141 mean?

I'll make a larger report after I will finish disassembling this virus!

- -Yuval Tal

+--------------------------------------------------------------------------+
| BitNet:   NYYUVAL@WEIZMANN       Domain: [e-mail] |
| InterNet: [e-mail]                        |
+----------------------+---------------------------------------------------+
| Yuval Tal            | Voice:   [phone]  (In Israel: 08-474592)    |
| P.O Box 1462         | BBS:     [phone] * 20:00-7:00 * 1200 * N81  |
| Rehovot, Israel      | FidoNet: 2:403/143                                |
+----------------------+---------------------------------------------------+
|  "Always look on the bright side of life" *whistle*  -  Monty Python     |
+--------------------------------------------------------------------------+

------------------------------

Date:    Thu, 07 Jun 90 18:03:00 -0400
From:    Software Release Engineering - LOTUS <[e-mail]>
Subject: Wanted - MDEF configuration for SAM (Mac)

    !-> I survived Southeastern Mass Uuu.,  7-JUN-1990

    Does anyone have a copy of the proper way to configure SAM 2.0 to
protect against MDEF/Garfield.  I can't remember if Paul Cozza already sent
it out and I missed it or if he just hasn't sent it out.
    I am also interested in finding out if there are any Rival users out
there who might already know how effective this init/cdev is against MDEF
and Steroid.
                        thanks much !->
                                   - Alex Zavatone - Software Release Engineer
                                     PCSD Mac - Lotus
s10891hk@semassu - bitnet
alex@Smuhep      - hepnet

------------------------------

Date:    Thu, 07 Jun 90 16:37:04 -0700
From:    [e-mail]
Subject: Brain (PC)

How does one outsmart the pakistani brain virus. I have found it on
several of my  disks some of which I don't have working backups for.
Stupid I know but there it is.

Michael Peer
usereawm.sfu

------------------------------

Date:    Thu, 07 Jun 90 23:31:25 -0400
From:    Tom Young <[e-mail]>
Subject: Steroid trojan query (Mac)

   Can anyone supply us all with info as to just where this Steroid trojan
has been found, what the presumed route of communication has been, etc.?
   Trojans, by their very nature, don't tend to spread as far as viruses.
Unless, perhaps, posted to a number of bulletin boards.  Or shrink-wrapped.
(Hmm.  I've certainly run across shrink-wrapped software that makes me feel
like I'm up against a trojan horse.  Operating systems, as well as applica-
tion packages.)  Where a trojan has appeared, and in how many different
places, will determine the nature of an organization's response.  I don't
like to push the panic button except when justified.
   Thanks much.
                        Tom Young
                        Cornell Information Technologies
                        Workstation Systems Services

------------------------------

Date:    Fri, 08 Jun 90 09:10:12 +0100
From:    Anthony Appleyard <[e-mail]>
Subject: First jailed UK computer hacker

>From a UK newspaper called 'The Daily Telegraph', Friday 8 June 1990:-

['Mad Hacker' jailed for computer war]

A computer operator who called himself "The Mad Hacker" became the first in
Britain to be jailed for the offence yesterday. Nicholas Whiteley,  21,  of
Enfield,  north  London,  was sentenced to 4 months with a further 8 months
suspended for criminally damaging computer  disks  and  wreaking  havoc  on
university  systems. Whiteley, who, it was said, was driven by a desire top
become Britain's top hacker, wept in the dock and held  his  hands  to  his
face as he walked to the cells to begin his sentence.

Judge Geoffrey Rivlin, QC, described him as "very malicious and  arrogant",
and  told  him:  "Anyone minded to behave in this way must be deterred from
doing so.".

Whiteley declared war on computer experts, using a computer in his  bedroom
to  swamp  university  computers  with masses of useless material including
threats and boasts about his brilliance. One  said:  "Don't  mess  with  me
because I am extremely nutty.".

He was found guilty last month of 4 charges of causing damage  to  magnetic
disks in mainframe computers at the universities of London, Bath, and Hull.
The judge said some of the computers stored important and confidential data
relating to medical and scientific research.
......................................................................
{A.Appleyard} (email: [e-mail]), Fri, 08 Jun 90 08:58:20 BST

------------------------------

Date:    Fri, 08 Jun 90 10:11:00 +0700
From:    "Tom Erjavec"<[e-mail]> x
Subject: 1451COM / 1411EXE ? new virus (PC) ?

Here is some (of the rare) news from Yugoslavia:

We have had some 'classical' PC viruses for two years now: 1701, 1704,
Brain, Bouncing Ball, Jerusalem (1813COM/1808EXE), Yankee Doodle like
(2885COM/2880EXE), Yankee Doodle (2772COM/2772EXE) and Disk Killer.
Now it seems we have another uninvited guest.

In early June I was given a sample of a virus, found in a small SW
engineering company. They detected no strange behaviour but prolongation
of COM and EXE files. I disassembled it and I'm posting a brief report:

VirusName       : ?, (1451COM/1411EXE)
Type            : indirect executable code infector
Infects         : COM and EXE files
VirusBodyLength : 1451 bytes (COM), 1411 bytes (EXE)
Expanding victim: YES, to paragraph boundary, both COM and EXE
Location in RAM : before end of memory
Steals interrupt: 21h
Intercepts func.: 40h (write to file), 4Bh (load & execute)
Attacks         : Sept., Oct., Nov., Dec., each year
Action          : When executing int 21h, func. 40h (write to file)
                  intercepts the call. If triggered the action code
                  increments register DX by 0Ah, changing the address
                  of buffer to be written to disk.
Consequences    : wrong data (or garbage) written to disk

Program package RETROVIR (c) Proteus detects and removes the
1451COM/1411EXE from disk, along with all the other viruses mentioned
above.

I will be glad to receive reports on this virus from elsewhere.
Does anyone know its origin?

Tom.

------------------------------

Date:    08 Jun 90 09:38:39 +0000
From:    Elizabeth A Sandland <[e-mail]>
Subject: Samsung S800 diagnostics

Has anyone out there any experience of running the diagnostics disk supplied
with the Samsung S800 (AT compatible)? Specifically, any problems when you
BOOT from this disk on a system with a hard disk?
(Please do not 'try it out' now to see what happens.)
Is there anyone out there who could examine the boot sector of said disk
and let me know if it looks OK?

I would like to pinpoint the source of a problem which occurred recently,
when a machine crashed unexpectedly.

THERE IS ABSOLUTELY NO IMPLICATION OF ANY SORT IN THE ABOVE QUESTIONS!!

Thanks,

Liz

-
 -------------------------------------------------------------------------------
Liz Sandland                                                   [e-mail]
Hardware Support Group
Department of Computing
Imperial College                                        Tel: [phone] x5048
London SW7 2BZ                                                Fax: [phone]
-
 -------------------------------------------------------------------------------

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 110]
******************************************VIRUS-L Digest   Monday, 11 Jun 1990    Volume 3 : Issue 111

Today's Topics:

Re: removing Stoned from harddisks (PC)
re: Brain (PC)
re: Possible virus or trojan (Mac)? Help!!!
Re: Possible virus or trojan (Mac)? Help!!!
Re: Creation of New Viruses to Sell Product
RE: Documented mainframe viral attacks
Re: removing Stoned from harddisks (PC)
Re: First jailed UK computer h
Re: New Virus (PC)
Soviet Virus Questions
Re: 1451 virus in Yugoslavia (PC)
First generation samples (PC)
Re: Possible virus (PC)
Military use of computer viruses
F-PROT version 1.10 (PC)
Ping-Pong Ball Virus (PC)
Citation request - "What Do You Feed A Trojan Horse"

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    08 Jun 90 12:37:27 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: Re: removing Stoned from harddisks (PC)

> he said that the tech from the disk company claimed
> that Stoned actually does destroy the media permanantly.

The Stoned virus that I've seen does nothing special that would
tend to destroy media; it just does normal reads and writes
via the BIOS INT13 interface.  It is of course possible that
there are Stoned variants out there that do nastier things, or
hardware that can be permanently damaged as an indirect result
of (for instance) having a bad partition table written on it,
but I've seen no convincing evidence of either...

DC

------------------------------

Date:    08 Jun 90 12:48:47 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: re: Brain (PC)

> How does one outsmart the pakistani brain virus. I have found it on
> several of my  disks some of which I don't have working backups for.

If you have the usual "Brain" virus on some diskettes, you can
just copy the data off of them onto clean diskettes (using COPY,
*not* DISKCOPY), and reformat them.   Be very careful, of course,
to do this in a machine in which the virus is *not* currently active!

DC

------------------------------

Date:    Fri, 08 Jun 90 14:32:40 -0400
From:    Joe McMahon <[e-mail]>
Subject: re: Possible virus or trojan (Mac)? Help!!!

>       b.  Suddenly icons can't find their applications
>       c.  Applications are increasingly unable to open data files or
>           find them

This sounds like a corrupted Desktop. Try rebuilding it.

>       d.  The parameters of applications like Versaterm are unaccountably
>           changing themselves i.e. the baud rate changes itself or the
>           Kermit parameters change for no known reason
>       e.  The options of the System and Desktop are unaccountably changing
>           themselves i.e. the sound bar is turned up without anyone having
>           done it.

These symptoms sound like a damaged System file at the least, possibly
some of the other files in the System folder are damaged too. You may
also need to replace your battery.

>       f.  There are more system bombs, and other disk and ram error messages
>           than I've ever seen before in two years of working with Macs.

This sounds like real hardware trouble. Maybe. Try the other stuff I
mentioned first. If the person taking the software was using an old
version of the System file (i.e., booted from a floppy), it's remotely
possible that may have done it.

 --- Joe M.

------------------------------

Date:    08 Jun 90 13:35:44 +0000
From:    vaxb.acs.unt.edu![e-mail] (C. Irby)
Subject: Re: Possible virus or trojan (Mac)? Help!!!

[e-mail] writes:
>      I've got a strange Mac problem and need help.  Monday night, one
>   of my colleagues allowed a friend in to the office to steal Mac software
>   (using his old Mac disks, of course).  After the appropriate cussing-out
>   and running-off, the machine in question (Mac SE, 20Mb hard disk, System
>   6.0.3) started acting funny.  Symptoms:

Before you do that- have you tried to reinstall the System software?
If your friend accidentally trashed a file or two, that could be the
easy fix...

Viruses?  Maybe, but who knows...?

C Irby

------------------------------

Date:    08 Jun 90 13:40:53 +0000
From:    vaxb.acs.unt.edu![e-mail] (C. Irby)
Subject: Re: Creation of New Viruses to Sell Product

[e-mail] writes:
>>This leaves a greater potential for companies to profit from the
>>creation of new viruses.
>
> New viruses do not sell product.  Old viruses sell product.  There
> are not enough copies of a new virus to be noticed.
>
> William Hugh Murray, Executive Consultant, Information System Security
> 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
> 203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

You're joking, right?

"New virus reported- 1 copy found- get your new virus killer here!"

For example, there are some companies that sell "yearly upgrade
support" for X dollars- if there are no new viruses, there *is* no
reason for the product...

C Irby
[e-mail]
ac08@untvax

------------------------------

Date:    Fri, 08 Jun 90 17:52:36 -0400
From:    Arthur Gutowski <[e-mail]>
Subject: RE: Documented mainframe viral attacks

[e-mail] (Gordon Spoelhof) asks:

>1.  How many mainframe viral attacks are documented?

The ones that come to my mind (and I believe all have been reported
here) are the XMAS, BUL, 4PLAY, and HEADACHE execs on VM/CMS and the
RTM worm and WANK worm on Unix.

>2.  How many incidents are reported/not reported?

Hard to say.  I suspect that just as with PC and Macintosh viruses, some
cases go unreported.

>3.  In general, how are the viruses introduced?

I'm not sure about the Unix worms, as I didn't follow them as closely,
but I believe they exploited mail/file xfer bugs/features.  The VM execs
used nickname files in PROFS and Rice Mail to send themselves to everyone
you knew as they ran.

>4.  What corrective measures had to be taken?

The only VM exec we encountered here was the origional XMAS exec.  Luckily,
we had alert tech support staff who monitored this list and Valert-L, caught
the thing when it first came in, and nipped it in the bud.

>5.  What preventative measures are taken?

One, never trust unexpected files from unknown sources.  Even though it may
not be a virus or worm as such, it has the potential of being a Trojan.
Two, monitor Virus-L/Valert-L for warnings of new/recurring problems.
Three, make sure your operations and tech support staff monitor things
like (on VM) spool space filling up with a certain filename, perhaps even
setting up filters in RSCS to reject all such files (when a confirmed report
is received).  News facilities to spread the word to users to be on the
lookout for such a file also help.
These are things that we've done to keep attacks to a minimum.

>6.  What is the level of risk?

So far, to my knowledge (corrections welcomed if I'm wrong), the only
threat the VM execs have posed is filling up spool space, which can
cause VM to crash, if the problem goes unnoticed.  However, there always
is the risk of a virus/worm carrying a payload that will format your A-disk,
erase certain key files, or whatever.

Basically, we try not to get caught with our britches down.  This list and
Valert-L are the good sources for new emergences. And staff awarness, along
with past experiences keep us on our toes.

  /==="   Arthur J. Gutowski, System Programmer
 : o o :  MVS & Antiviral Group / WSU University Computing Center
 : --- :  Bitnet: AGUTOWS@WAYNEST1  Internet: [e-mail]
  \===/                                       [e-mail]
 Have a day.
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Waiter:  Would you care for some coffee, sir?
 DesCartes:  I think not.                   ...*Poof!*, gone.

------------------------------

Date:    09 Jun 90 01:27:10 +0000
From:    btr!public![e-mail] (Giovanni V. Guillemette [e-mail])
Subject: Re: removing Stoned from harddisks (PC)

plains![e-mail] (Brett G. Person) writes:
>I had a friend call me who told me that Stoned actually damaged the
>media on the hard drive.  He said they lost a full ten Meg. He took
>the drive through a low-level + dos format, and only wound up with
>20Meg on a 30 meg disk.
>
>Now, I know that a piece of software isn't supposed to physically
>destroy media, but he said that the tech from the disk company claimed
>that Stoned actually does destroy the media permanantly.  I don't
>pretend to know everything about the pc, do I told him I'd ask here.
>My bet is that the drive was either mis-labled as a 30 meg, or somehow
>partitioned wrong.
>
>- --
>Brett G. Person
>North Dakota State University
>uunet!plains!person | [e-mail] | [e-mail]

This has happened to me before, but not in relation to a virus.  It happened
when I tried to format an RLL drive in MFM format, as RLL offers 50% more
data per track.  Run CHKDSK on the disk.  If you get a message to the effect
that you have 10 megs of bad sectors, then it's media damage.  If not, then
it's because you didn't partition the disk properly.  Here's how:

Use a program like Ontrack's Disk Manager, or Speedstor to do your low-level
format.  It will ask you for the drive type - and, in both cases, you should
be able to enter the specific disk (assuming it's a Seagate, but, even if it's
not, Speedstor might still have it) by brand and model.  Then, let the program
partition it for you, using the *default* values.  What it will do is to create
a small (<1MB) MFM partition for DOS to boot off of (obviously, that's where
you load your system), and another 31MB RLL partition, which DOS will only be
able to access after loading the device driver that Disk Manager (or Speedstor)
loads automatically on the first partition for you.  Hope I didn't confuse you.

One caveat:  The disk program will install a device driver and a default
CONFIG.SYS file.  Make sure you don't remove the "device=[driver].sys" file
from your CONFIG.SYS, or you won't be able to access the 31MB partition!

Let me know if that helps.  This is my first posting ever to the net (I'm new
to Unix, but not DOS), and I don't want to think I'm wasting bandwidth.

    - Gio
[e-mail]
73677,[e-mail]

(I may be new to Unix, but I've heard of the line eater.  Eat this!)

------------------------------

Date:    Sat, 09 Jun 90 07:44:00 +0000
From:    Costas Krallis <[e-mail]>
Subject: Re: First jailed UK computer h

An important point is that he was convicted for serious criminal
damages, not for hacking which is not really illegal by itself. He was
not just a hacker but a computer vandal.

Costas Krallis
London, UK

E-Mail:   <[e-mail]>

PS: The word "hacker" here is used to describe a "password cracker"
    but has also other meanings. Please, let refrain from the flame
    war about it.

------------------------------

Date:    Sat, 09 Jun 90 07:38:00 +0000
From:    Costas Krallis <[e-mail]>
Subject: Re: New Virus (PC)

Yuval Tal <[e-mail]> writes:

> I've just received a copy of a virus called "Armagedon the GREEK".
> Have anyone ever seen this virus? SCAN 62 did not identify this virus
> so I consider this as a new virus. I've checked it a bit and from what
> I found out, at a certain time, the virus sends a special command to
> your ports which a Hayes compatible modem can understand!

Is it really a virus or just a trojan ? Any inteeresting copyright
strings in the program ?

> Greek fellows: What does the phone number 081-141 mean?

081-141 is the phone number where you can hear the time announcement
in Iraklion, Crete.

Costas Krallis G7AHN
E-Mail:  <[e-mail]>

------------------------------

Date:    Sat, 09 Jun 90 15:42:00 -0500
From:    Sanford Sherizen <[e-mail]>
Subject: Soviet Virus Questions

I recently returned from a technical study mission to the USSR,
participating with a group of specialists reviewing EDP audit, data
security, and quality assurance.  Experts from universities,
ministries, and financial organizations (both state and private) kept
mentioning their concerns with virus (Russian pronunciation=vee'rus)
attacks. There have been a number of virus problems even though there
is *very* restricted access to machines and minimal network links to
the outside.  Soviet systems seem ill prepared to prevent virus
epidemics, except for some homegrown scanning programs. Current plans
to expand computerization within the public as well as private sectors
will create opportunities for many problems.

I am interested in hearing from anyone who has information about the following:

        1.  Incidents of virus problems in the USSR (I have some details from

            the November, 1988 period but nothing else.)

        2.  Vaccines or other virus prevention/detection programs in the USSR

        3.  Western virus prevention/detection programs that are available for

            export to the USSR

Finally, I mentioned Virus-L in my talks and there were many people
who were interested in obtaining its messages.  Does anyone know of
existing links that could be used to make Virus-L available to Soviet
researchers and other interested parties given current official and
technical restrictions over their receiving external messages?

Any assistance that you can offer will be appreciated.  I plan to send
information to people there and will be writing a number of articles
on the findings from my trip.

Nice to be back in the U.S.

Sandy Sherizen

******************

Sanford Sherizen

RESPOND VIA-------------------> MCI MAIL:   SSHERIZEN  (396-5782)
           -------------------> FAX:        [phone]
           -------------------> PHONE:      [phone]

******************

------------------------------

Date:    Sat, 09 Jun 90 22:41:00 -0400
From:    Paul Coen <[e-mail]>
Subject: Re: 1451 virus in Yugoslavia (PC)

>VirusName       : ?, (1451COM/1411EXE)
>Type            : indirect executable code infector
>Infects         : COM and EXE files
>VirusBodyLength : 1451 bytes (COM), 1411 bytes (EXE)
>Expanding victim: YES, to paragraph boundary, both COM and EXE
>Location in RAM : before end of memory
>Steals interrupt: 21h
>Intercepts func.: 40h (write to file), 4Bh (load & execute)
>Attacks         : Sept., Oct., Nov., Dec., each year
>Action          : When executing int 21h, func. 40h (write to file)
>                  intercepts the call. If triggered the action code
>                  increments register DX by 0Ah, changing the address
>                  of buffer to be written to disk.
>Consequences    : wrong data (or garbage) written to disk

From the trigger time, location in RAM, and the action/result, this
sounds remarkably like the 1554/1559 virus.  We were hit with it in
March/April here at Drew U.  One thing we noticed was that it doesn't
always add the same amt. to a file -- ours tended to be around 1300+
bytes.  However, Viruscan and the dissasembly indicated that it was
the virus commonly known as the 1554.  I'd guess that yours is the
same beastie.

I could be wrong, but I think it originated in Taiwan.  My first
recollection of it was when someone from Taiwan posted a UUENCODED
.COM file (chkdsk, I think) containing the virus to the VALERT-L list.

I haven't heard of too many places getting hit -- supposidly we were
only the third or so reported hit in the United States.

We (Drew U. Academic Computer Center) figured that it was probably
written by/for students in particular -- since the trigger time
roughly corresponds to the fall semester in many places.

McAfee's viruscan (the latest version in v63) detects the 1554.  I'd
be interested in knowing if that is what it identifies your virus as.

One other item of note -- the virus we were hit with doesn't go TSR
by calling the standard interrupt(s).  It just writes itself in the
upper 128K (on a 640K machine) and hopes nothing writes over it.
Because of this, it blows right by programs watching the interrupts,
like FluShot+.  If this is the method that your virus uses, I'd say
it's almost certainly the same virus -- or a variant.

It's a nasty bug -- it might look like a disk error to the uninformed.
Good luck with it.

                        ------------------------
Paul Coen                                               Drew University
           [e-mail]               [e-mail]

------------------------------

Date:    Sun, 10 Jun 90 14:16:38 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: First generation samples (PC)

When the author of a virus wants to get his creation into circulation,
he might send a copy of it to a virus researcher - probably because it
is a fast and easy way to get the publicity he wants.

Sometimes this is done anonymously, but the author could just as well
claim to have "found" the virus on some computer.  It is even possible
that this might be done in order to establish a good working
relationship with the virus researcher - with possible virus exchanges
in the future in mind.

It is so much easier to write a virus when a starting point, in the
form of an existing virus is provided.

The question is: Has this ever happened ? Are any of the virus samples
that have been made available to researchers "first-generation copies"
directly from the virus authors ?

Several such cases are known - Murphy-2, New Vienna, the TP-series and
Icelandic-2, and the Pentagon "virus" might also be included in the
group.

There are also a few cases where the sample originally made available
for research is not a typical infected program, as it includes a text
string or a piece of code which is not included when the virus
replicates.  In some cases the virus is structurally different,
missing a 3-byte JMP at the beginning for example.  This only seems to
be possible if...

       ...the person who made the virus available is the author
or
       ...he obtained the virus directly from the author

This article is written because a few days ago I obtained two new
viruses, where the samples are different from typical infected
programs - clearly the samples were first-generation programs.

Those two viruses were called SVIR.EXE (a 512 byte direct-action .EXE
file infector) and 13J.EXE, a 1201 byte encrypted .EXE file infector.

Some previous such cases were known, including the Amoeba (a 1392 byte
.EXE and .COM infector), but I suspect that several other viruses have
also been distributed by their authors this way.

- -frisk

Fridrik Skulason      University of Iceland  |
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: [e-mail]    Fax: [phone]  |

------------------------------

Date:    11 Jun 90 03:46:33 +0000
From:    [e-mail] (Woody Baker @ Eagle Signal)
Subject: Re: Possible virus (PC)

[e-mail] (SEAN KRULEWITCH) writes:
> prompt.  When I try again, I get an incorrect Dos version error.  If I
> then proceed to type ver it says Dos 3.41.  However I am running Dos
> 4.01.  If i type ver a few more times it continues to say dos 3.41.

This sounds like one of the 4.01 bugs.  DON'T EVEN LET dos 4.X NEAR a
machine.  It causes all kinds of strange problems.  I have a long
string of friends and aquaintances who have tried it, and have had to
go back to dos 3.x for reliablity.  The technical reasons for this are
many and varied, but the major culprit seems to be the 32 bit fat
table.  Some of the function calls have been modified.  Specificaly,
some of the older calls did not specify the contents ofthe CX register
pair.  Under DOS 4.01 the CX register pair is checked for a specific
value, to enable 32 bit fat stuff.  Since this was not a requirement
that CX have anything in it, some programs use it for a counter etc.
etc.  These programs can crash bigtime in certain cases.  DON'T USE
DOS 4.X

Cheers
Woody

------------------------------

Date:    Mon, 11 Jun 90 10:12:36 +0100
From:    Anthony Appleyard <[e-mail]>
Subject: Military use of computer viruses

{A.Appleyard} (email: [e-mail]), Mon, 11 Jun 90 09:54:04 BST
......................................................................
from UK newspaper 'The Sunday Telegraph', Sunday 10 June 1990

[Germ war looks to computer virus], by Roger Highfield, Science Editor

A new era of warfare - "electronic garm warfare" - is about to be launched.
Computer viruses are to be developed  into  weapons.  Viruses,  destructive
rograms  that  can  propagate  undetected  through computer networks, could
wreak havoc on battlefield computers, disabling communications  and  making
weapons  useless.  "We're  looking  to see if we can develop some malicious
software concepts.",  said  Dr.  Richard  Poisel,  chief  of  research  and
technology  at  the  secretive  US  Army  Centre  for  Signals  Warfare  in
Warrenton, Virginia, USA. One security expert, Professor Lance  Hoffman  of
George  Washington  University, said advanced nations were most vulnerable.
"Their military systems are much more dependent on computers.".

Details of the attack virus are  contained  in  the  "Program  Solicitation
90-2" issued in the Defence Department's Small Business Innivation Research
Programme.   Entitled  "Computer  Virus  Electronic  Counter  Measure",  it
outlines how the research "shall be to determine the  potential  for  using
computer viruses as an electronic counter measure technique against generic
military  communications  systems/nets.". The project not only calls on the
company to design the viruses but to determine if they can  be  transmitted
by  radio  to  infect the enemy's computer. One potential target of viruses
could be organizations like the Government Communications  Headquarters  in
Cheltenham  (UK),  which  intercept  foreign radio transmissions and decode
them by computer. Once in an enemy system, the virus could lurk  undetected
until  required.  It  could  scramble  data,  infect  another computer, and
possibly even go on to delete itself.

The US Department of Defence has offered an initial $50,000  to  businesses
prepared to undertake a feasibility study.

------------------------------

Date:    Mon, 11 Jun 90 10:40:17 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: F-PROT version 1.10 (PC)

F-PROT version 1.10 is now finished.  The major changes since 1.09 include:

          * Scanning and disinfection of LZEXE-packed files.  This is rather
          slow, as it is written in C.  I version 1.11 this routine will be
          written in assembly language.

          * A bug in F-DISINF that prevented it from removing the 'Stoned'
          virus from hard disks has been corrected.

        * Some command line options added: /AUTO to automatically remove
          any infections found, without asking.

        * Support for the Bulgarian version (P16) of DOS.

        * The programs can now detect, stop and remove numerous new viruses -
            including Shake, Victor, 5120, Jo-Jo, Liberty, Murphy, 800, Fish 6
          and Form. The number of virus families is now 81, major variants
          (different infective lengths for example) are around 120 and total
          number of variants is over 150.

The German version is not ready yet - those I have promised a copy of
it will have to wait a bit longer.

I will send a copy to those on my mailing list tomorrow, as well as
upload a copy to SIMTEL, if possible - we often have problems reaching
SIMTEL from here.

- -frisk

Fridrik Skulason      University of Iceland  |
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: [e-mail]    Fax: [phone]  |

------------------------------

Date:    Mon, 11 Jun 90 13:36:35 +0000
From:    Bechaa Mahmoud <[e-mail]>
Subject: Ping-Pong Ball Virus (PC)

I found the ping-pong ball virus on 3 of our pc hard disks.  Symptoms:
a ball bouncing on the screen and destroying characters.  The program
seems to choose whether to activate itself or not. So, we can
sometimes see it run and sometimes not. The problem is : I am not very
used to viruses and to the way to fight them. I would like to know if
such a virus can attack EXE and COM files and what is the best way to
definitively stop the infection.

I have tried reinstalling the system files by a 'SYS c:' command, but
many students have disks already infected and they reintroduce the
virus when they work on the PC. I wonder if programs like SAM (on Mac)
exists for pc systems. It would be a good solution, the floppy disk
being always controled and treated if an infection is detected. Can
anyone give me all the suggestions to help me stop the virus.

i                           Groupe ESC Lyon                             i
i                      23 Avenue Guy de Collongue                       i
i                            69130 - Ecully                             i
i                                France                                 i

------------------------------

Date:    Mon, 11 Jun 90 08:32:00 -0500
From:    [e-mail]1
Subject: Citation request - "What Do You Feed A Trojan Horse"

Would anyone have the text of Clifford Stoll's address
"What do you feed a Trojan horse?" given at Proceedings of the 10th National
Computer Security Conference (Baltimore, Md. Sept 21-24, 1987)

As usual, send responses, comments directly to me.  I will summarize
for the net if there is interest.

Brian Jacoby, [e-mail]

In tribute to Jim Henson, a.k.a. Grover:

   N    N EEEEE  AAA  RRRR
   NN   N E     A   A R   R
   N  N N EEE   AAAAA RRRR
   N   NN E     A   A R  R
   N    N EEEEE A   A R   R         far

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 111]
******************************************VIRUS-L Digest   Tuesday, 12 Jun 1990    Volume 3 : Issue 112

Today's Topics:

George of the Jungle virus????? (Mac)
More George of the Jungle... (Mac)
Flushot version? (PC)
SNEAK - a virus? (Mac)
Re: Creation of New Viruses to Sell Product
Re: Documented mainframe viral attacks
What's the best pc clone virus protection pgm? (PC)
The "Tiny" virus (PC)
Hardware security
- Virus's and Solutions
Inbound File Filters (IBM Mainframes)
NETSC63B.ZIP in Simtel Archives (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    11 Jun 90 14:54:01 +0000
From:    [e-mail] (charles he hemstreet)
Subject: George of the Jungle virus????? (Mac)

I work at a computer lab here on campus, and we had someone come in
and ask about this..  I may not ahve this totally correct...

WHAT IT DOES.....

1. It's a file in the system folder...

2. If you open it (it say's it's a word perfect document) it causes the
system to crash and gives message that says it can't open it, and that
it needs wordperfect to open it.  (Opposite order listed)

3. Comes and goes, not consistent.  First noticed it on Friday the 8th.

4. Not associated with anything purchased.

5. Seems to have quite a bit of activity.

6. Virus protection and disinfectant schemes don't seem to care that
it's around.


I know this is vague.  Please help me ask the person the correct
questions so I can help you out more.  Is there any kind of
standardized virus report form?

Thanks for your help.  We are currently trying to obtain a copy of
this thing.  Still not sure if it's a virus or not.

Thanks for your help...

Chip

!===========================================================================!
! Charles H. Hemstreet IV       !internet: [e-mail] !
! Colorado State University     ! "stay out of trouble!" -RoboCop           !
!===========================================================================!

------------------------------

Date:    11 Jun 90 15:07:29 +0000
From:    [e-mail] (charles he hemstreet)
Subject: More George of the Jungle... (Mac)

Well, I'm not sure what I've got here, but may not be as serious as I
thought.  We have got a copy here at the lab.  It's has the
WordPerfect feather on a trashcan Icon.  I opened it on an isolated SE
by double-clicking on the trash/feather icon.  WordPerfect complains
that it can't open this kind of document.  On the isolated SE,
WordPerfect goes ahead and opens an untitled document.

Is this a standard WordPerfect Icon?  The person found this document
in his system folder.  I have a copy on floppy if anyone would care to
look at it.

Chip

!===========================================================================!
! Charles H. Hemstreet IV       !internet: [e-mail] !
! Colorado State University     ! "stay out of trouble!" -RoboCop           !
!===========================================================================!

------------------------------

Date:    Mon, 11 Jun 90 08:26:50 -0700
From:    Robert Slade <[e-mail]>
Subject: Flushot version? (PC)

I have seen a copy of FSP_17.ARC on wuarchive.wustl.edu.  The latest
version I was aware of was 1.6.  Ross having not been terribly active
on the list lately, does anyone know if this is legit?

------------------------------

Date:    Mon, 11 Jun 90 17:14:45 +0000
From:    [e-mail],
           [e-mail] (Michael Rys)
Subject: SNEAK - a virus? (Mac)

Configuration:

Mac II and Mac IIcx connected over TOPS.

There were some problems with printing, saving, opening files etc.
Using Disinfectant 1.8 did not find any viri. Interferon 3.1
reported a SNEAK virus. Some time ago, somebody said this is not aa
virus.

What is it then?!!!

Any help appreciated.../Michael

+---------------------------------------------------------------+
| Michael Rys, V. Conzett Str. 34; CH-8004 Zuerich; Switzerland |
+---------------------------------------------------------------+
| UUCP:  [e-mail] or       EAN:     [e-mail]  |
|        [e-mail]       IPSANet: mrys@ipsaint                |
| Voice: [phone]                                              |
+---------------------------------------------------------------+
- -- Wovon man nicht sprechen kann, darueber muss man schweigen. --
       Ludwig Wittgenstein, Tractatus logico-philosophicus

------------------------------

Date:    11 Jun 90 19:45:54 +0000
From:    [e-mail] (Mike Cummings )
Subject: Re: Creation of New Viruses to Sell Product

[e-mail] writes:
>>This leaves a greater potential for companies to profit from the
>>creation of new viruses.
>
>New viruses do not sell product.  Old viruses sell product.  There
>are not enough copies of a new virus to be noticed.

This is true in the short term, but every virus has to start small, even
the biggest and most prolific.  A company looking far to its future -
ie. a couple of years, might stand to benifit from such a policy.

I'd hate to think that it would happen though - it's pretty morally
reprehensible.  It's like a drug company developing and releasing new
diseases, just to keep up the demand for new medicines.  On the other
hand, I don't think that it is too likely.  There are two reasons for
this:
(i) the dangers for the company are too great.  If any news of such
activity was leaked or discovered, it would be curtains in a big way.
Such security compromises are just too likely for the company to risk
it.
(ii) more impiortantly perhaps,  is that companies distributing virus
scanners are unlikely to need to resort to such tactics.  We don't seem
to have any lack of new viruses out there.  Hackers seem only too ready
to write, and worse yet, distribute viruses.  Until we educate such
criminals in responsible use of computers, virus scanners will be a
healthy business.

- ------->>>>>>>>>>>>>  [e-mail]

------------------------------

Date:    Tue, 12 Jun 90 02:16:17 +0000
From:    [e-mail] (Peter da Silva)
Subject: Re: Documented mainframe viral attacks

[ Supposed mainframe virus attacks ]

> The ones that come to my mind (and I believe all have been reported
> here) are the XMAS, BUL, 4PLAY, and HEADACHE execs on VM/CMS and the
> RTM worm and WANK worm on Unix.

I don't know about the others, but the XMAS was a trojan horse worm, RTM was
a directly attacking worm, and the WANK worm was on VAX/VMS, not UNIX.

All of these, I believe, used network utilities and mail programs to infect
hosts.
- --
`-_-' Peter da Silva. [phone].  <[e-mail]>
 'U`  Have you hugged your wolf today?  <[e-mail]>
@FIN  Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.

------------------------------

Date:    11 Jun 90 22:48:00 -0500
From:    "55SRWLGS" <[e-mail]>
Subject: What's the best pc clone virus protection pgm? (PC)

          Like to get some opinions on this one. If you could only get
one program for your pc/pc-xt/pc-at or clone, what would it be? This
is dicey, I know, what with viruses constantly evolving.
          Recently a lot of folks have been leaning towards McAffee's
SCAN program. Then there was one by a fellow, whose name escapes me
right now. He was offering a reward of a cache of free software to
whomever turned in a virus programmer, and helped get him/her arrested
and convicted.
          Anyway, appreciate a lot of opinions, and experiences, good or
bad. I think we may be getting up a site liscense deal, and so I need
some help towards getting the best for the buck.

Frank Starr
Omaha, Nebraska  ([e-mail]>"

------------------------------

Date:    Tue, 12 Jun 90 09:54:01 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: The "Tiny" virus (PC)

Among the 10 (or so) new PC viruses which have appeared this month is
one which is by far the smallest one known - only 163 bytes.

It is very primitive - does not restore the original date/time of
infected files for example.  In fact, it does nothing but replicate.

The virus infects only .COM files, by adding itself to the end and
placing a 3-byte JMP at the beginning.  When an infected program is
run, the virus will search the current directory for a program to
infect.

"Tiny" seems to be based on the Kennedy virus, and was sent to me from
Denmark by the same person who sent me a sample of Kennedy.

- -frisk

------------------------------

Date:    11 Jun 90 15:01:33 +0000
From:    <[e-mail]>
Subject: Hardware security

I have had a quote attributed to me that was not mine.  I would
appreciate it greatly if people would get their facts straight before
posting messages.  And don't whine about your Mail program not working
right.  If it doesn't work, trash it!

The quote that was attributed to me was actually posted by Mike
Cummings.  The person who falsely paired me to this quote was Valdis
Kletnieks.

Now to reply to Valdis:

I agree with Mike!  This is a stupid thing to do!  What is the
point of having hardware protection if it is so easy to defeat!
Perhaps you are not familiar with the PS/2s.  Some of them can
have the case removed in under 15 seconds, and the wire could be
swapped in another 3.  Close the case in another 15.  Copy a diskette
in one minute.  Power the machine off.

There!!!  In less than two minutes in your office, I can steal
confidential files off your hard drive that you THOUGHT were protected
by hardware protection.  I can do that during the day while you walk
to the coffee pot and back.  If however, I had to disable your machine
for two hours to eliminate your password, it would be MUCH more obvious
that something was happening.
Or do you lock your door every time you leave your office?

Later
THE GAR

------------------------------

Date:    12 Jun 90 09:30:34 +0700
From:    <[e-mail]>
Subject: - Virus's and Solutions

I have 2 questions about viruses please can some body answer??

q1. There is a virus which reduce speed of booting plus reduce
capacity of drive i.e you can't read high density diskette drive on it
will be only 360k.  What is the virus name and what is the solution???

q2. Virus lives in memory when you put system off you can't get rod
off it, It will go to clock ROM chip!! Is there any solution other
than disconnecting battery??

Thanks in advance

Azim Syed
Systems Programmer
Riyadh Saudi Arabia

------------------------------

Date:    Mon, 11 Jun 90 17:50:24 -0400
From:    "David F. Lambert" <[e-mail]>
Subject: Inbound File Filters (IBM Mainframes)

>Date:    Fri, 08 Jun 90 17:52:36 -0400
>From:    Arthur Gutowski <[e-mail]>
>Subject: RE: Documented mainframe viral attacks
>
>[e-mail] (Gordon Spoelhof) asks:
>.
>.
>>5.  What preventative measures are taken?
>
>One, never trust unexpected files from unknown sources.  Even though it may
>not be a virus or worm as such, it has the potential of being a Trojan.
>Two, monitor Virus-L/Valert-L for warnings of new/recurring problems.
>Three, make sure your operations and tech support staff monitor things
>like (on VM) spool space filling up with a certain filename, perhaps even
>setting up filters in RSCS to reject all such files (when a confirmed report
>is received).  News facilities to spread the word to users to be on the
>lookout for such a file also help.
>These are things that we've done to keep attacks to a minimum.

I just saw an IBM announcement a week or two ago which mentioned free
security enhancements for RSCS.  Several of these features looked
pretty useless, except for one which provides the file filter
mentioned above.  That seems like a useful hunk of code to help nip
things quickly.
                                                   -Dave

------------------------------

Date:    Mon, 11 Jun 90 22:53:00 -0400
From:    <[e-mail]>
Subject: NETSC63B.ZIP in Simtel Archives (PC)

Maybe I missed the little write up on Virus-L about the new Netscan but why
the new version? I looked in the documentation and it doesn't say anything
about the "B" version. Maybe the moderator can quickly clear this up for me?
Thanks.
Santo Nucifora ([e-mail])

P.S. Just being a little cautious :-)

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 112]
******************************************
[1356] (558 lines) Network_Server.Daemon 06/14/90  1329.7 edt Thu VIRUS-L
Subject:  VIRUS-L Digest V3 #113
From: [e-mail]

VIRUS-L Digest   Thursday, 14 Jun 1990    Volume 3 : Issue 113

Today's Topics:

re: - Viruses and Solutions (PC?)
Re: First jailed UK computer hacker
Anti-viral philosophies
Re: Hardware security
Re: Hardware protection
RE: Documented mainframe attacks (IBM Mainframe)
Re: Possible virus (PC)
need virus-l undigestifier for PC or MAC
New Stoned Virus Strains and Killer Available (PC)
George of the Jungle: Not to worry? (Mac)
Password Standards Checking
UnVirus 9.02 (PC)
Is This a Virus? (PC)
Re: - Virus's and Solutions

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    12 Jun 90 12:06:04 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: re: - Viruses and Solutions (PC?)

Azim Syed <[e-mail]>:
> q2. Virus lives in memory when you put system off you can't get rod
> off it, It will go to clock ROM chip!! Is there any solution other
> than disconnecting battery??

I've never seen such a virus, although people like to talk about
the possibility.   It seems very very unlikely to me; at least
in IBM-supplied systems, the clock memory (battery-supplied CMOS
RAM, not ROM), is very small, and is in the I/O space, not the
memory space.   There's nothing in the system that will execute
code stored there, even if there were room for a virus.   So
I wouldn't worry about it too hard, myself!   Of course, if you
have a file that you think actually contains such a virus, I'd
be very interested to see it.   But rumors are only worth what
they cost...                           DC

------------------------------

Date:    Tue, 12 Jun 90 15:56:15 +0000
From:    [e-mail]
Subject: Re: First jailed UK computer hacker

"The Times" of London carried the following report on Friday, 9th June 1990

Headline: Prison for "mad hacker"

>A teenage computer hacker who broke into university systems and destroyed
>vast amounts of material was yesterday jailed for four months. Nicholas,
>Whitely now aged 21, called himself "the mad hacker" and waged his six-month
>war in 1988 from a home computer in his bedroom.

What purpose is served by sending Whiteley to prison for 4 months or for
1 year? He will now be locked with two other inmates in a cell designed
for one person for a substantial majority of the day at one of Her Majesty's
Universities of Crime. What should we expect him to do except pass on his
rare skills to other felons?

Why was there no Community Service Order which would have obliged him to
spend all his spare time undertaking positive actions to the society which
he had damaged? Once free from gaol he will have all the time in the world
... to continue hacking.

Why were the prosecution denied their request for costs? Since it appears
Whiteley can return to work at the Opera, a weekly decuction towards costs
(although no more than a flea-bite towards the actual costs) would seem
in order.

I'm not sure about confiscating his computer - but I can understand the
argument.

On the surface it does not seem to be a brilliant day for the British
judiciary. Perhaps the judge thinks that hacking has something to do with
riding horses ...

Ian Leitch
Head of Computing Services
London School of Hygiene and Tropical Medicine

------------------------------

Date:    Tue, 12 Jun 90 13:39:05 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: Anti-viral philosophies

>         Like to get some opinions on this one. If you could only get
>one program for your pc/pc-xt/pc-at or clone, what would it be?

          This is a question that keeps coming up and while I agree that
McAfee's products are the best for someone who knows what they are doing,
they are not products that are suitable for environments with vast numbers
of PCs and semi-educated users, rather they are ones that the technicians
should use as part of their toolkits to diagnose & repair problems. There
are several reasons for this:

1) Can you imagine trying to install monthly updates on 5000 PCs. If you can,
   where do you get funding for the diskettes/labour ?
2) These utilities require a fair amount of knowlege to use e.g. use of the
   /d option will erase infected files that might be copy protected/install
   once programs while not using /M or /A may miss some infections.
3) Indescriminant use will wipe out any hope of determining the infection
   vector.

          What I prefer is a package that resides in the background of the user's
PC and reports any change to the environment with no appreciable hit to
performance (SCAN can take over ten minutes to process a 40 Mb disk now and if
LZEXE-type compression is used can extend this materially).

          Such a package should be able to check the environment that exists
when invoked (to catch boot sector infectors & previous infections), should
flag immediately an attempt to run an "unknown" program, maintain signatures
of "approved" executables, and create an audit trail for any changes.

          This would require three classes of machine:
1) Restricted:  can run only files currently on system.
2) Privileged:  can add files to system, runs new files after authentication.
3) Development: can run new files from certain drives/directories without
                authentication.

          Not that none of this requires authentication of the user, there are
many other products that will do this, rather it allows execution only of
authenticated files in an authenticated system. Should a deviation occur,
the event is flagged on the screen and a menu is presented depending on class.

          When an event occurs that indicates an unauthorized change has taken
place, then is the time for a tech to come out with SCAN and other tools to
determine what has happened, all the resident tool is required to do is to
determine that SOMETHING unauthorized has happened.

          Note that no attempt is made to block any specific malicious software,
rather ALL un-authenticated software is treated as suspect. Additionally, if
a virus is passed, a trail is created and detection of an environmental change
is flagged.

          It would seem that most of the advanced anti-viral researchers, being
"power-users" have developed single-stage tools for their individual needs,
not the for corporate/govenmental/educational environment that is better served
by multi-stage tool sets. There are a few such tools available, but they are
in the minority.

------------------------------

Date:    Tue, 12 Jun 90 14:00:08 -0400
From:    Valdis Kletnieks <[e-mail]>
Subject: Re: Hardware security

>There!!!  In less than two minutes in your office, I can steal
>confidential files off your hard drive that you THOUGHT were protected
>by hardware protection.

Actually, I don't lock my office..  we have those 5 foot high partitions
around here.  But anyhow - a moment's though shows that leaving the door
*OPEN* may be more secure - if everybody EXPECTS the office to be empty
and locked, nobody will check - but if it's supposed to be empty and the
door open, the case of 'door open and guy kneeling in plain sight
ripping open my PS/2' is pretty obvious to the other programmers walking
by.....

My point was:  If you have enough time to get into my office and pop the
covers, you could walk out with all of the following:

The ethernet board, the 8514 driver board, the 8M memory board, the hard
disk controller, and the 300M hard disk.  Pop the boards, put them into
your pocket, drive goes under your jacket.

You've just walked off with all my confidential files, plus a lot of
nice hardware.  Decode the files at home at your leisure.

Of course, if I was gonna go this far, I'd just dress like a deliveryman,
bring in a dolly, put the PS/2 on it, put a cardboard box over it, and
take the whole damned thing....

I repeat - if the enemy can physically walk off with it, it doesn't MATTER
if there's some silly-ass battery-backup password on it - they'll have all
weekend to poke at it on their workbench.

>From all accounts I've heard, the major problem with PC's in
public-access terminal rooms is *not* people opening them up and
sabotaging them, but people figuring out how to unbolt them from the
table and walking away with the whole machine...

Physical security is nice - let's just make sure we're defending against
the right problem...

                                  Valdis Kletnieks

------------------------------

Date:    Tue, 12 Jun 90 15:01:17 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: Re: Hardware protection

G. L Warner writes:

>From:    <[e-mail]>
>What is the point of having hardware protection if it is so easy to defeat!

The following is a posting made in reference to the "boot from floppy vs
hard disk" conflict with reguard to viruses. I feel that it has use here:

          To me, the most secure method would be a boot from a protected floppy
that initiates the checking/authentication routine before leaving the floppy
(realize that I avoid hardware approaches which though better involve $$$.
Floppies are cheap). The next level would use a non-DOS hard disk only
accessable with a special device driver only on the floppy (multiple backups
are a good idea). Seagate's DM program for formatting disks permits this and is
easy to obtain. This way, even if someone booted from another floppy, the hard
disk would not be accessable.
        Beyond this, we get into any number of encryption schemes (no Aryeh,
EBCDIC is not encrytion) possible purely with software - as long as the key is
kept on the boot floppy, it is difficult to extract any data even if the entire
disk is stolen (and I have seen a few instances of this).
        About now, the subject of ROM passwords usually comes up.
Unfortunately, all that I have seen (Compaq, PS/20, etc) provide some form of
maintenance retrieval that negates the purpose. Some are even trivial
(reversing a plug or popping a connection) for anyone with physical access.
        Consequently, if the disk requires physical protection, the best
safeguard is removing and locking up the disk. If not, floppy-booting with
software protection is enough for the job. Anything else is a compromise.

------------------------------

Date:    Tue, 12 Jun 90 17:49:40 -0400
From:    Arthur Gutowski <[e-mail]>
Subject: RE: Documented mainframe attacks (IBM Mainframe)

>From:    [e-mail] (Peter da Silva)
>
>I don't know about the others, but the XMAS was a trojan horse worm, RTMwas
>a directly attacking worm, and the WANK worm was on VAX/VMS, not UNIX.
>
>All of these, I believe, used network utilities and mail programs to infect
>hosts.

I thought that the Unix worms spread similarly to the VM worms.  Yes, XMAS
was really a trojan worm, I wasn't careful on my wording, and I wasn't sure
if they behaved like RTM or Wank.  As a matter of fact, the BUL, 4PLAY, and
HEADACHE were more or less XMAS clones.

>From:    "David F. Lambert" <[e-mail]>
>
>>From:    Arthur Gutowski <[e-mail]>
>>...
>>Three, make sure your operations and tech support staff monitor things
>>like (on VM) spool space filling up with a certain filename, perhaps even
>>setting up filters in RSCS to reject all such files (when a confirmed report
>>is received).  ...
>
>I just saw an IBM announcement a week or two ago which mentioned free
>security enhancements for RSCS.  Several of these features looked
>pretty useless, except for one which provides the file filter
>mentioned above.  That seems like a useful hunk of code to help nip
>things quickly.

I think we found out about it sometime around the XMAS attack because we
asked IBM directly...evidently there's been enough interest to make it
available.  It can be useful, but care must be taken not to abuse it--
that's why I stressed "when a confirmed report of a VM worm is received."

/art

PS>  IBM == I've Been Moved

------------------------------

Date:    12 Jun 90 23:22:33 +0000
From:    [e-mail] (roy schmidt)
Subject: Re: Possible virus (PC)

[e-mail] (Woody Baker @ Eagle Signal) writes:
>This sounds like one of the 4.01 bugs.  DON'T EVEN LET dos 4.X NEAR a
>machine.  It causes all kinds of strange problems.  I have a long
>string of friends and aquaintances who have tried it, and have had to
>go back to dos 3.x for reliablity.  The technical reasons for this are
>many and varied, but the major culprit seems to be the 32 bit fat
>table.  Some of the function calls have been modified.  Specificaly,
>some of the older calls did not specify the contents ofthe CX register
>pair.  Under DOS 4.01 the CX register pair is checked for a specific
>value, to enable 32 bit fat stuff.  Since this was not a requirement
>that CX have anything in it, some programs use it for a counter etc.
>etc.  These programs can crash bigtime in certain cases.  DON'T USE
>DOS 4.X

Really, now!  I've been running DOS4.01 for over a year now, without a
hitch.  It would be interesting to see which programs your friends
have had problems with, as I have run all the major business programs
and a number of games without any troubles....but this conversation
belongs in another group.  This fella with the strange DOS version
messages, etc, seems to be in the clutches of some sort of doctored
code, which is doing things he did not want done, which I believe is
the name of the game for this group.  THIS IS NOT A DOS BUG!!!

- -----------------------------------------------------------       ^
Roy Schmidt                 |  #include <disclaimer.h>           | |
Indiana University          |  /* They are _my_ thoughts,        | |
Graduate School of Business |     and you can't have them,      <   >
Bloomington                 |     so there! */                    X
___________________________________________________________       X

------------------------------

Date:    12 Jun 90 18:35:35
From:    "Philip H. Arny" <[e-mail]>
Subject: need virus-l undigestifier for PC or MAC

Hi out there --
I've been printing virus-l and putting it in a binder.  This is
starting to seem silly, so I think I'll download the digests,
run them through an "undigester" program, and load them into a
textbase.

So -- Is there an undigester program sitting out there?  Where could
I get it?  Mac or PC would be fine.

Philip Arny
lrc1@umnhsnve
[e-mail]

------------------------------

Date:    Wed, 13 Jun 90 14:01:00 -1200
From:    Pat Cain <[e-mail]>
Subject: New Stoned Virus Strains and Killer Available (PC)

Recently we have discovered a new strain of the Stoned Virus.  It is not
detected by programs as SCAN, VBUSTER and KILLER.

We believe that this virus probably hasn't spread too far, and possibly
a student created it and brought it into Victoria University.

We have seen various copies of this new strain with different messages,
such as:
  "Your PC is Stoned!  - version 2"
  "Donald Duck is a lie"
   and also a blanked out message.

We have produced a killer "NoStone" for this new strain that detects
and removes both the new and old strains.  If anyone wants a copy of
this, then we can send it 'uuencoded' through e-mail and we could also
upload it by ftp to a PC anti-viral site if required.
- ---

::: Details :::

We have disassembled the new strain and compared it against the original
strain (that also seems to have come from Wellington, NZ).

* If a machine is infected with the old strain, then the new strain will
  not infect the machine (it has code in it to ensure this).

* If a machine is infected with the new strain and it then gets infected
  with the old strain then there are problems:
  The new strain is moved by the old strain onto where the new strain had
  stored the Master Boot Record (MBR).  When this happens, there is no
  copy of the MBR and the next time the machine is booted the two strains
  continually re-load themselves reducing the memory each time until there
  is no memory remaining and the machine crashes.

  If you don't have a backup of the MBR then you are in trouble,
  'NoStone' automatically saves a copy of the MBR when it is first run
  and detects if the hard disk has been doubly infected, and if so
  recovers the partition table.

For anyone who is interested in this new strain, the author has made a
a commented dissasembly of the new strain and has noted the differences
between the two strains.  He would prefer to provide this only to people
who have a valid reason for requiring it (such as those who wish to change
their virus killers to check for this new strain).

To contact the author Simon McAuliffe, e-mail: [e-mail]
- -----------------------------------------------------------------------------

Pat Cain, [e-mail]

------------------------------

Date:    Wed, 13 Jun 90 07:16:00 -0400
From:    [e-mail]
Subject: George of the Jungle: Not to worry? (Mac)

Quote:
"Is this a standard WordPerfect Icon?  The person found this document
in his system folder.  I have a copy on floppy if anyone would care to
look at it.

Your document sounds like a WP Undelete File 1 (ICN#137). Since it's a
temporary File it should come and go. See the manual (p.640 in mine).

- ----------------------------------
Richard Howland-Bolton
Manager Publications Computing
Cornell University
Internet: [e-mail]
Compuserve: 71041,2133
Voice: [phone]
FAX: [phone]
Etc, etc.
- ----------------------------------

------------------------------

Date:    Wed, 13 Jun 90 09:12:24 -0400
From:    "Chuck Sechler" <[e-mail]>
Subject: Password Standards Checking

Some breakins to a computer at a university in Ohio has prompted us at
Ohio State to look into enforcing use of more obscure passwords on our systems.
I looked around on listserv groups for a security list, but could not find one.
So, I am trying these lists.

Basically, we want to know if there has been any work on MVS and CMS platforms,
to keep users from picking obvious passwords, like their name, password same
as userid, password is a word, etc. On MVS we are working on Top Secret
package, and it has some interesting capabilities for restriction, including
generating random passwords, when a user if forced to change their password,
but it is not ready yet. Some UNIX platforms check passwords against  very
large lists of restricted words(like 50000 or more). Any thoughts? Should this
be on a different list?

------------------------------

Date:    Wed, 13 Jun 90 16:37:14 +0300
From:    Y. Radai <[e-mail]>
Subject: UnVirus 9.02 (PC)

  Every once in awhile someone posts to this list a cry of anguish
like "Help, I think we've got the XXXXXX virus!  What should we do?"
Well, of course every regular reader of VIRUS-L knows that one can use
McAfee's SCAN and CLEAN or Skulason's F-DISINF or F-FCHK, not to men-
tion various commercial programs.  But sometimes there's a specific
request for *freeware* (often erroneously called "public domain" soft-
ware).  I recently sent an archive of such software, UNVIR902.ZIP, to
Keith Petersen for uploading to SIMTEL20 (directory <MSDOS.TROJAN-PRO>)
and to Jim Wright for uploading to other sites.  This archive contains
two programs by Rakavy and Mann, the virus removal program UnVirus 9.02
and the resident program Immune 9.00.  UnVirus 9.02 eradicates the:
    Stoned (Marijuana)
    4096 (Frodo)
    Jerusalem (1813)
    Ping-Pong (Bouncing Ball)
    Brain (Pakistani)
    Vienna (648)
    DataCrime
and several other viruses.
  Obviously, UnVirus 9.02 can't compete with the other programs men-
tioned above in number of viruses removed, but when one takes into
account the *frequency* of infections by each virus, this list ac-
counts for 70% of all infections (according to the report by David
Chess in Issue 90).
  A new version of UnVirus is being developed which will detect almost
as many viruses as those programs, and will be much faster than them.
Preliminary tests indicate that it's twice as fast as SCAN and seven
times as fast as F-FCHK.  (It's possible that F-FCHK can catch more
mutations of known viruses, but that remains to be tested.)  Moreover,
the time required by the new UnVirus is independent of the number of
viruses scanned for, so its speed relative to these other programs
will increase as the number of viruses increases.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     [e-mail]

------------------------------

Date:    13 Jun 90 16:29:37 +0000
From:    [e-mail] (Bob Lombardi 44139)
Subject: Is This a Virus? (PC)

I've been having a wierd problem with my 386 machine that I thought
I'd see if anyone had seen before.  Is this a virus?

After the system has been running for a while, a bad DOS command or
search for a file out of the current directory will cause the system
to halt and display "All data on the selected unit will be destroyed.
Proceed (Y or N)?".  The message comes from the BIOS prom on the hard/
flopy controller.  It thinks it wants to format the hard disk.

The system is a 25 MHz clone, with motherboard by PC-Calc (I think) that
uses a Chips & Technologies chipset.  The hard drive is a SCSI 80 Meg
Seagate ST-296N with an ST-02 controller.  Everything else in the system
has been changed out.  The OS is DOS 4.01.  We have been running 4DOS (in
the evaluation period), but removing it has no effect.  Booting from a
floppy thought to be "clean" (virus free), with nothing in either
config.sys or autoexec.bat, has no effect on the problem.

We have replaced the controller card, and run with every other card in
the system removed.  We swapped a CGA card for the VGA card.  Only the
motherboard (my suspicion), the hard drive and the floppy have not been
swapped out. If it is a virus, it is undoubtedly on the hard disk by
now.

If anyone has seen anything like this, please email to me. If interest is
shown, I'll post back to this newsgroup.

Thanks......Bob

Bob Lombardi             /-/-/    |Internet: [e-mail]
Mail Stop 102-4826         |      |phone: [phone]
Harris Corporation GASD    |      |Packet:WB4EHS @ (temp. out of service)
P.O.B. 94000, Melbourne FL 32902  |Never mistake motion for progress.

------------------------------

Date:    13 Jun 90 16:40:40 +0000
From:    [e-mail] (Sam Shim)
Subject: Re: - Virus's and Solutions

[e-mail] writes:
>I have 2 questions about viruses please can some body answer??
>q2. Virus lives in memory when you put system off you can't get rod
>off it, It will go to clock ROM chip!! Is there any solution other
>than disconnecting battery??

I can't answer question one but I can answer question two.  I know of no virus
that can reside in the clock RAM (not ROM) chip and I really really doubt
that is is possble.  The CMOS RAM stored is usually very small (around 64
bytes) and most of that is used for maintaining the date/time, CMOS
configuration, etc...  I doubt anyone can make a virus that small, and even
if they could, the CMOS RAM is not executable so it would just sit there
doing nothing.  So it wouldn't even replicate so I doubt you can even consider
it a virus.  A virus might be smart enough to store some of its code in
CMOS ram (like counting how often that virus has been executed), but most
of its code would still have to be on your drive.  And because of that, the
virus can be detected and removed.  Sounds like someone's giving you some
bad information about viruses.

 -----------------------------------------------------------------------------
|  Sam Shim                                   | "I didn't do it...            |
|  EECS Departmental Computing Organization   |  It wasn't me...              |
|  University of Michigan                     |  Nobody saw me do it...       |
|  Ann Arbor, MI 48109                        |  Nobody can prove a thing..." |
|  internet: [e-mail]              |  - Bart Simpson               |
 -----------------------------------------------------------------------------

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 113]
******************************************From: [e-mail]

VIRUS-L Digest   Friday, 15 Jun 1990    Volume 3 : Issue 114

Today's Topics:

RE: Documented mainframe viral attacks
Re: George of the Jungle virus????? (Mac)
Re: More George of the Jungle... (Mac)
VSHIELD and Windows 3.0 (PC)
Re: removing Stoned from harddisks (PC)
Vanishing Disk Space (PC)
re: UnVirus 9.02 (PC)
Re: Flushot version? (PC)
GateKeeper Aid 'ADBS' Query (Mac)
Mainframe viruses, theoretical (Murray)
Strange floppies (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 13 Jun 90 17:46:32 +0100
From:    Alan Thew <[e-mail]>
Subject: RE: Documented mainframe viral attacks

>[e-mail] (Gordon Spoelhof) asks:
>
>>1.  How many mainframe viral attacks are documented?
>
>The ones that come to my mind (and I believe all have been reported
>here) are the XMAS, BUL, 4PLAY, and HEADACHE execs on VM/CMS and the
>RTM worm [UNIX] and WANK worm [VMS].

There was also  the DIR exec (VM)  which was supposed to give  a DOS type
display of  files but,  I believe,  after a  certain date  formatted your
minidisk. We never saw it but were warned by a number of lists.

Alan Thew
University of Liverpool Computer Laboratory
Bitnet/Earn: [e-mail] or QQ11%UK.AC.LIVERPOOL @ UKACRL
UUCP       : ....!mcsun!ukc!liv!qq11        Voice: [phone]
Internet   : [e-mail] or QQ11%LIVERPOOL.AC.UK @ NSFNET-RELAY.AC.UK

------------------------------

Date:    13 Jun 90 17:28:10 +0000
From:    [e-mail] (charles he hemstreet)
Subject: Re: George of the Jungle virus????? (Mac)

[e-mail] (charles he hemstreet) writes:

   From: [e-mail] (charles he hemstreet)
   Newsgroups: comp.virus
   Date: 11 Jun 90 14:54:01 GMT

   I work at a computer lab here on campus, and we had someone come in
   and ask about this..  I may not ahve this totally correct...

[much stuff deleted]

After some response (many thanks) and thought.  I and the person
involved have decided that this was a prank against him.  The tool
used was simply ResEdit.  The prankster edited the STR resource of the
application and the icon resource.  We are currently looking to set up
some security on his machine.  Thanks again for the help.  Much appreciated.

Chip
- --
!===========================================================================!
! Charles H. Hemstreet IV       !internet: [e-mail] !
! Colorado State University     ! "stay out of trouble!" -RoboCop           !
!===========================================================================!

------------------------------

Date:    13 Jun 90 17:31:32 +0000
From:    [e-mail] (Glenn L. Austin)
Subject: Re: More George of the Jungle... (Mac)

[e-mail] (charles he hemstreet) writes:

>Well, I'm not sure what I've got here, but may not be as serious as I
>thought.  We have got a copy here at the lab.  It's has the
>WordPerfect feather on a trashcan Icon.  I opened it on an isolated SE
>by double-clicking on the trash/feather icon.  WordPerfect complains
>that it can't open this kind of document.  On the isolated SE,
>WordPerfect goes ahead and opens an untitled document.

>Is this a standard WordPerfect Icon?  The person found this document
>in his system folder.  I have a copy on floppy if anyone would care to
>look at it.

It sounds like that is a temporary document from the description of
the location of the file and the icon.  It's pretty easy to check
using MultiFinder or a file DA (like DiskTop).  Make sure that the
file is removed from the system folder, launch WordPerfect, and check
for the file.

- -----------------------------------------------------------------------------
| Glenn L. Austin               | "Turn too soon, run out of room,          |
| Auto Racing Enthusiast and    |   Turn too late, much better fate"        |
| Communications Toolbox Hacker |   - Jim Russell Racing School Instructors |
| Apple Computer, Inc.          | "Drive slower, race faster" - D. Waltrip  |
| Internet:   [e-mail] |-------------------------------------------|
| AppleLink:  AUSTIN.GLENN      | All opinions stated above are mine --     |
| Bellnet:    [phone]    |                who else would want them?  |
- -----------------------------------------------------------------------------

------------------------------

Date:    Wed, 13 Jun 90 15:36:00 -0400
From:    Jim Shanesy <[e-mail]>
Subject: VSHIELD and Windows 3.0 (PC)

Has anyone loaded VSHIELD into memory before invoking Windows 3.0?  If
so, did Windows functions properly?  Is the ability to detect viruses
at all compromised?

Jim Shanesy @ National Research Council, National Academy of Sciences

------------------------------

Date:    Thu, 14 Jun 90 07:31:42 +0000
From:    plains!umn-cs!LOCAL![e-mail] (Brian Aslakson)
Subject: Re: removing Stoned from harddisks (PC)

btr!public![e-mail] (Giovanni V. Guillemette [e-mail]) writes:
>plains![e-mail] (Brett G. Person) writes:
>>I had a friend call me who told me that Stoned actually damaged the
>>media on the hard drive.  He said they lost a full ten Meg. He took
>>...
>This has happened to me before, but not in relation to a virus.  It happened
>when I tried to format an RLL drive in MFM format, as RLL offers 50% more
>...
>Use a program like Ontrack's Disk Manager, or Speedstor to do your low-level
>format.  It will ask you for the drive type - and, in both cases, you should
>be able to enter the specific disk (assuming it's a Seagate, but, even if it's
>not, Speedstor might still have it) by brand and model.  Then, let the program
>partition it for you, using the *default* values.  What it will do is to creat
e
>a small (<1MB) MFM partition for DOS to boot off of (obviously, that's where
>you load your system), and another 31MB RLL partition, which DOS will only be
>able to access after loading the device driver that Disk Manager (or Speedstor
)
>loads automatically on the first partition for you.  Hope I didn't confuse you
.

Wrong!!!!  Or rather, right but there is a much better way.  First tho,
Disk Manager (a fine Minnesota company) makes software for more than Seagate
drives.  Also, you can make a full size partition using Ontrack software
(no need to make some Mickey Mouse 1 meg partition).
Call them at 1-800-752-1333.  That said, I'd advise against using
their software in your case.  Better you should format it using regular
DOS methods.  (Yes, I agree with the second writer, it sounds like an MFM
vs RLL problem).  If you have a Western Digital controller card, you are
in luck, cuz they too have a free number, with a snazzy recorded help that
you can navigate with a touch tone phone.  WD's number is:  1-800-356-5787.
Otherwise find someone who nows DOS there and can come over and walk you
through it.  Going the straight DOS way is best, you can avoid all sorts
of headaches later.

Luck!

Brian

NB:  I've tried to post this 3 times and if you ain't reading this, I've
probably exploded into 500 billion pieces.

------------------------------

Date:    14 Jun 90 14:54:36 +0000
From:    [e-mail] (Michael Lorengo)
Subject: Vanishing Disk Space (PC)

          Does anybody know anything about a virus that eats up disk space.
Currently on this Network when I do a CheckVol the amount of free diskspace
seems to dwindle to 0.  I delete some old files, and in a matter of minutes
I have no more free space left.
          This is on a Novell Network and Zenith 386's.

------------------------------

Date:    14 Jun 90 14:27:44 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: re: UnVirus 9.02 (PC)

Y. Radai <[e-mail]>:

> the time required by the new UnVirus is independent of the number of
> viruses scanned for, so its speed relative to these other programs
> will increase as the number of viruses increases.

If you don't consider it proprietary, I'd be curious to know what
the scanning algorithm is that it doesn't slow down as the number
of viruses increases.

DC

------------------------------

Date:    14 Jun 90 17:41:23 +0000
From:    [e-mail] (Mitch Wagner)
Subject: Re: Flushot version? (PC)

[e-mail] (Robert Slade) writes:
#I have seen a copy of FSP_17.ARC on wuarchive.wustl.edu.  The latest
#version I was aware of was 1.6.  Ross having not been terribly active
#on the list lately, does anyone know if this is legit?

I forwarded the question to Ross Greenberg, who has lost his USEnet
connection for a while, and he sent me the following reply, which he
asked me to forward to comp.virus:

"Alas, I've lost my net connection for a short while.  But, to answer your
question:  Version 1.7 of FLU_SHOT+ is the current version. A new version is
due out shortly.  New versions are available from my own BBS (212)-889-6438
(2400/n/8/1), from COMPUSERVE (check PCMagNet's UTILFORUM DL's) and from
BIX, as well as from any ASP-approved disk distributor: these are all copies
I can vouch for in the non-Usenet world.  In the Usenet world, any of the
anti-virus archives is probably safe and I know that SIMTEL20 (thanks,
Keith!) is a safe place to download from.

Back on more regularly when I get a Usenet connection back...

Ross"

- --
   -- Mitch Wagner                            Voice - 516/562-5758
                                              [e-mail]
                                              uunet!utoday!wagner

------------------------------

Date:    Thu, 14 Jun 90 12:33:00 -0700
From:    "Hervey Allen" <[e-mail]>
Subject: GateKeeper Aid 'ADBS' Query (Mac)

A member of our computing center uses GateKeeper Aid on her Macintosh IIcx
and has received the following message:

          GateKeeper Aid found an "Implied Loader 'ADBS' virus in the Desktop
          file on the "Animal Sanctuary" disk.  The virus was removed.

"Animal Sanctuary" is the hard disk she was booting her machine from.  Gate-
Keeper Aid has caught and removed Wdef A from her machine on several
occasions.  No disk was inserted when this message appeared.  She runs
Microsoft QuickMail, Vaccine, AppleShare, and GateKeeper Aid.

I may be asking a question that's already been answered, but I couldn't
remember seeing any remarks about "Implied Loader 'ADBS' viruses" when
using GateKeeper Aid.  If anyone could tell me, or hazard a guess as to
what GateKeeper Aid found and what an "Implied Loader 'ADBS' virus" is I
would greatly appreciate it.  Please send replies directly to me if this
is something that has been discussed before.]

Thanks In Advance!

Hervey Allen  <<Bitnet:   [e-mail]>>
              <<Internet: [e-mail]>>

Microcomputer Assisstant/Virus Consultant
University of Oregon Academic Computer Services

* Disclaimer:  The opinions expressed here are my own and in no way reflect *
*                the opinions of the University of Oregon.                    *

------------------------------

Date:    Thu, 14 Jun 90 12:22:27 -0400
From:    Arthur Gutowski <[e-mail]>
Subject: Mainframe viruses, theoretical (Murray)

>I would not want to get into an argument about it, but the difference
>in age is not significant.  Unix is much older than you might guess.
>...
>I doubt that this is true in terms of years or hours.  It is likely
>true in terms of determination and other resources.  Total reported
>integrity flaws in MVS have likely been in the high tens.  Almost
>none eere detected or exploited by hackers.  Most were detected by people
>with special knowledge and training after the expenditure of significant
>resources.

Agreed, the ten or so years MVS has on Unix isn't as significant.  This
was only a response to a statement about the number of people trying to poke
holes in Unix is greater than in MVS.  The knowledge of the people involved
and other resources used have a bigger impact.

My impression from the mainframe discussions that Unix attracts a
different class of attackers than does MVS or VM.  That none of the
MVS flaws had been exploited by hackers, but by knowledgeable people
with the specific purpose of finding holes, and Unix source code is
available (at least to some), intuitively it seems that Unix would be
easier to break into than MVS by non-systems people.  By the same token,
I suppose it would be easier to enhance Unix security.  Take into
consideration that information about MVS isn't readily available to
people outside of systems work.  hmmmmm......

>Your confidence is poorly placed.  While MVS and VM are as secure as IBM
>knows how to make them collectively, individual installations or instances
>are likely no better than instances of Unix.  People who do penetration
>studies of MVS and VM for a living report that eighty-five percent will
>yield to a knowledgeable attacker in hours to days.  Most will yield to
>a determined attacker in days, and less than one percent will stand up
>for weeks.

Maybe so, maybe not.  Perhaps I take it for granted (somewhat) because
our installation keeps track of access controls (although there is still
room for improvement).  These penetration studies appear to contradict that
experienced people with the aid of special training and a large amount
resources only turned up integrity flaws in the high tens.  These studies
would suggest that number should be much higher.  I do doubt that anyone
but the systems people or very good applications people are going to be
able crack MVS, and then it's a case of having trustworthy people on staff.

*Some* instances of MVS or VM probably are no better (indeed, even worse)
than Unix (or for that matter, PCs).  This is a tsoris spot here too;
what good is buying an OS and a security system with  all the necessary
controls if you're going to cripple it?  I still feel MVS is a more secure
system, as long as you don't compromise what was put in place by IBM and
your security system vendor.

>...MVS installations are rife with very general utilities that run
>privileged and have poor controls.

So what?  One, joe-user doesn't have the ability to interrupt while the
utility is in supervisor state and do his own thing (OS integrity).  Two,
keep privileged programs (i.e., APF authorized) restricted to what comes
with the system, and systems people putting in any needed in-house
authorized programs (good security practice).

>All of this has little to do with their vulnerability to viruses.  As
>Dave Chess of IBM Research has tried to explain on this list several
>times, viruses exploit the privileges of users rather than flaws in
>the environment.  Operating system integrity and access controls will
>only slow them.  If users have the privilege to execute an arbitrary
>program of their choice, can create or modify a procedure, and share
>data with a sufficiently large population of peers, then that is all
>that is required for the success of a virus.
>
>The trick to the success of a virus is not in its code, but in how you
>get it executed!

True, it does have little to do with viruses.  I did (and still do) agree
with what Dave has said; I think what this discussion evolved from is
a devil's-advocate scenario I had used:  "how does joe-user spread a virus
if he can't write to data other than his own, and other people can't
execute his programs."  No access controls or system integrity measures
in the world can prevent a virus from spreading around "legally" accessed
data.  The trick is indeed how you get it executed, and if the data is
widely shared, there isn't much magic involved.  You just have to know how
to stay in the user's address space and latch onto the next program that
gets executed.

If you restrict access, it becomes trickier to spread.  This, like you
said comes down to individual installations and how they have their system
set up (hopefully they're at least smart enough to protect their payroll
data from attacks :-) ).

  /===\   Arthur J. Gutowski, System Programmer
 : o o :  MVS & Antiviral Group / WSU University Computing Center
 : --- :  Bitnet: AGUTOWS@WAYNEST1  Internet: [e-mail]
  \===/                                       [e-mail]
 Have a day.
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Disclaimer:  Hey, what do I know?  I'm only a tourist.

------------------------------

Date:    Thu, 14 Jun 90 20:32:03 -0400
Subject: Strange floppies (PC)
From:    A. Padgett Peterson <[e-mail]>

In view of the myriad questions concerning oddly acting floppies, here
is the source code for a massive program written in a most
sophisticated and little known language (to be virus-free) that will
tell you what the CMOS thinks your floppy disk configuration is. This
has been through an extensive V&V program (five minutes - I had to
change the CMOS setup each time & reboot) on 1) a clone 386 with AMI
Bios and 2) a Zenith AT with the Zenith 386 kit. It may even work on
something else (usual disclaimers apply). I am sure that a neat little
.COM could be developed but Ken can post this.

5 PRINT CHR$(10);"AT/386/486 CMOS floppy drive record check.
6 PRINT "Copyright (C) 1990 by Padgett (though trivial)";CHR$(10)
10 FLOC=16
20 OUTC=112
30 INC=113
40 OUT OUTC,FLOC
50 FREC=INP(INC)
60 FLOP$=HEX$(FREC)
70 F$=LEFT$(FLOP$,1)
80 GOSUB 140
90 PRINT "First floppy drive record indicates:  ";R$
100 F$=RIGHT$(FLOP$,1)
110 GOSUB 140
120 PRINT "Second floppy drive record indicates: ";R$;CHR$(10)
130 END
140 R$="Unknown code: "+F$
150 IF F$="0" THEN R$="Not Present"
160 IF F$="1" THEN R$="360k  5 1/4 "
170 IF F$="2" THEN R$="1.2M  5 1/4 "
180 IF F$="3" THEN R$="720k  3 1/2 "
190 IF F$="4" THEN R$="1.44M 3 1/2 "
200 RETURN

Good luck - Padgett

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 114]
******************************************
VIRUS-L Digest   Monday, 18 Jun 1990    Volume 3 : Issue 115

Today's Topics:

Re: Password Standards Checking
New PC Virus (PC)
armageddon the GREEK virus (PC)
What do I do about Yankee Doodle
RE: GateKeeper Aid 'ADBS' Query (Mac)
Virus Catalog
Mainframe attacks (MVS)
Re:Vanishing Disk Space
Gatekeeper Aid and the ADBS "virus" (Mac)
GateKeeper Aid 'ADBS' Query (Mac)
Re: Password Standards Checking
F-PROT via FTP (PC)
Help requested with a purported Yankee Doodle infection (PC)
Discussion: definitions of common computer beasts (ie. viruses..)
FORM-Virus (PC)
Re: Password Standards Checking

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    15 Jun 90 10:24:40 +0000
From:    [e-mail] (Solitair)
Subject: Re: Password Standards Checking

You should try the alt.security list.  There has been a fairly elaborate
discussion about this topic on that newsgroup.
- --
Sincerely,                         | [e-mail]
           Stephen R. van den Berg | ...!uunet!mcsun!unido!rwthinf!cip-s01!berg

------------------------------

Date:    Fri, 15 Jun 90 15:44:09 -0500
From:    Christoph Fischer <[e-mail]>
Subject: New PC Virus (PC)

We reveived a HEX-Dump of a new virus via FAX (disk is still in mail)
from what we analysed sofar we can tell it is the sought after
                    AMBULANCE CAR VIRUS.
infects COM files (796 Bytes long), does multiple infections upon
invocation!
More after the complete analysis.

Christoph Fischer

*****************************************************************
* Christoph Fischer                                             *
* Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
* D-7500 Karlsruhe 1, Zirkel 2, Tel.: [phone]           *
* E-Mail: RY15 at DKAUNI11.BITNET                               *
*****************************************************************
'Christoph Fischer   [e-mail]  6/15/90 New virus (PC)

------------------------------

Date:    Thu, 14 Jun 90 02:08:06 +0700
From:    [e-mail]
Subject: armageddon the GREEK virus (PC)

*****************************************************************************
*                                                                           *
*           Vaccine for the >> Armagedon the GREEK <<  virus                *
*                                                                           *
*               (c) copyright 1990       George Spiliotis                   *
*               English documentation by Lefteris Kalamaras                 *
*****************************************************************************

This is a public domain program. It is in NO way allowed for anyone to sell
this program or its documentation for profit. (Usual public domain rules apply)

DISCLAIMER

The author of this program is in NO way liable for any damage caused by this
program, its use or its modifications. (Usual disclaimer rules apply)


                       "Armageddon the GREEK" scan


 I received a copy of a program recently, which contained a virus SCAN V62
could NOT identify! After having worked on its code for some time, I discovered
the following:

1) The virus becomes resident in memory
2) It infects .COM files ONLY
3) It sends the message "Armageddon the GREEK" to the 4 com ports from time to
time

It is possible that this virus is a modified existing one in which the author,
by changing the message to "Armageddon the GREEK", managed to get SCAN V62
inoperative.

This program is a vaccine for "Armageddon the GREEK". It can also scan and
clean modified versions of this virus if the only thing changed is the message.
You can stop the vaccine from cleaning the infected files from the virus by
specifying "/n" in the command line.

VALIDATE gave the following results:
          File Name:  scanarma.exe
               Size:  7,584
               Date:  6-1-1990
          File Authentication:
               Check Method 1 - C9FC
               Check Method 2 - 192C

Examples:

(SCANARMA c:      (checks drive c:)
(SCANARMA a:\temp (checks drive a: dir temp)
(SCANARMA /n b:   (checks b: but does NOT clean the infected files)
(
Good Luck!

For more information, you can contact the author of the vaccine, George
Spiliotis at the address below, or call LinK BBS in Athens, where you will
find the latest version of the vaccine, or send a message to LEKA@GRATHUN1
to contact Lefteris Kalamaras.

    George Spiliotis
    26-28 Digeni st. Voula
    Athens, 16673 GREECE

    or

    Lefteris Kalamaras
    43 Serifou st. K.Patissia
    Athens 11254 Greece
    BBS phone : [phone]
    voice #   : 30-1-864-5363
    BitNet    : LEKA@GRATHUN1 or ELKALAMARAS@VASSAR

------------------------------

Date:    15 Jun 90 20:21:28 +0000
From:    ctycal![e-mail] (Terry Ingoldsby)
Subject: What do I do about Yankee Doodle

We have had an outbreak of the Yankee Doodle virus (as detected by
ViruScan).  We now realize that we have a variety of tools to detect
viruses, but now that we've caught it we don't know what to do about
it.  Any suggestions?  We are not an Internet site, but might be able
to persuade a local site to get us something.  Help.

- --
  Terry Ingoldsby                ctycal![e-mail]
  Land Information Services                 or
  The City of Calgary       ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb

------------------------------

Date:    Fri, 15 Jun 90 16:31:53 -1100
From:    Michael Perrone <[e-mail]>
Subject: RE: GateKeeper Aid 'ADBS' Query (Mac)

It could be a WDEF clone, or a new implied loader type virus.  Gatekeeper
aid is designed to detect and remove any virus of this type.

Michael Perrone, Portland State University, Computing Services; Macintosh
Programming and support.

------------------------------

Date:    16 Jun 90 00:38:54 +0000
From:    [e-mail] (J. Barichnakov)
Subject: Virus Catalog

Does anyone know when the next version of the virus catalog is to be
published??????? I am presently writing a paper based on Computer
Viruses and would appreciate any information that can be found.
(Thanks to those people that have already sent me the Virus catalog's
MSDOSVIR.A89 and MSDOSVIR.290).

                    Thank's In Advance
                                        [e-mail]

------------------------------

Date:    Fri, 15 Jun 90 22:13:25 -0400
From:    Tony Harminc <[e-mail]>
Subject: Mainframe attacks (MVS)

In 1974 the University of Toronto installed MVS for academic
computing.  Within one week of installing this supposedly secure
system, an integrity exposure had been found and exploited by the
community of undergrad hackers who had spent a lot of effort hacking
the older (and known to be full of holes) MVT.  (Historical details on
request if anyone cares.)

I think mainframe hacking was much more popular in those days simply
because mainframes were all there were.  I don't know of any viruses,
but some quite diabolical things were invented.  Certainly Trojans
were common on the APL system, and a couple were successfully
perpetrated on the operations staff.  There were also a couple of
schemes concocted to clog up the network with endlessly shuttling
files.  ("The network" then consisted of two computers.)

------------------------------

Date:    14 Jun 90 17:14:52 +0000
From:    [e-mail] (Michael Lorengo)
Subject: Re:Vanishing Disk Space

          Please disregard the previous message, it seemed that it was
          a word perfect file that was eating up disk space, it seemed
          a station was left in word perfect, on the directory screen,
          and the a certain file on that station grew to 66,433,323 bytess
          once we deleted that file, the problem was gone.

------------------------------

Date:    Sat, 16 Jun 90 17:17:14 -0500
From:    [e-mail] (Chris Johnson)
Subject: Gatekeeper Aid and the ADBS "virus" (Mac)

A copy of a posting by Hervey Allen ([e-mail]) was recently
relayed to me by Werner Uhrig.  Mr. Allen was looking for an explanation of
the nature of the 'ADBS' virus that Gatekeeper Aid had recently discovered
on a co-worker's Mac IIcx.

Here's the story:

First, the co-worker is using version 1.0 of Gatekeeper Aid.  That version
is seriously flawed by one major bug which was caused by a terribly inaccurate
sentence in Inside Macintosh.  Unfortunately for us all, the bug didn't cause
any problems for me or my 1.0 testers, so it wasn't caught until it was
released.  :-(  Anyway, please upgrade to the current version which is 1.0.1.

Anyway, the 'ADBS' problem is unrelated to that one major bug.  The source
of this problem is the selection by Adobe of the 'ADBS' file creator code
for their Adobe Separator utility.  You see, 'ADBS' (as a resource type)
had been reserved by Apple since 1987 for storing the code that drives the
Apple Desktop Bus.  Since all file creator codes are represented in the
Desktop file as resources of the same type, having a program on a disk
with a file creator code of 'ADBS' results in the creation of an 'ADBS'
resource in the Desktop file.  Gatekeeper Aid knows that resources of
types reserved for storing executable code don't belong in non-executable
files like the Desktop, so it alerts you to their presence and removes
them.  This means that as soon as Gatekeeper Aid notices that 'ADBS' has
been added to the Desktop file, it will remove it.

Of course, this also means that as soon as the Finder next comes across
the Adobe Separator utility, it will look in the Desktop file to make sure
it's entry is there.  The Finder will then discover that Separator doesn't
have an entry (the 'ADBS' resource has been removed by Gatekeeper Aid), so
the Finder will add the 'ADBS' back into the Desktop file, and the cycle
begins anew once more.

I don't know whether Apple's creator code registration folks inadvertantly
allowed Adobe to give 'ADBS' to Separator because they were unaware of this
issue, or whether Adobe just made an unfortunate selection of creator codes,
but I have heard from one gentleman at Adobe about this matter.  I suggested
to him that Separator's creator code should be changed at the next opportunity.
I don't know whether or not the code actually will be changed as it should be,
but I hope so.  Are there any Adobe folks out there?  Can you get this changed?

(As an aside, Separator is not the only program ever to receive a file
creator code that was already assigned to an executable resource type.
Two other utilities exist with this problem.  One uses the 'FKEY' type and
the other uses the 'FMTR' type.)

Anyway, Gatekeeper Aid 1.0.1, in addition to correcting the major bug
mentioned earlier, deals more gracefully with this 'ADBS' problem.  First,
it attempts to determine whether or not suspicious resources in the Desktop
file are actually legitimate Desktop file entries before removing them.
Second, it doesn't refer to suspicious resources found in places they
don't belong as "viruses" - this conclusion was unfounded and caused too
much concern among those who saw the alerts.  Suspicious resources are now
referred to as merely "Implied Loader resources", which is what they actually
are.

So, once again, please upgrade to version 1.0.1 of Gatekeeper Aid.  Not only
did it eliminate one very nasty bug, but it eliminates these false alarms
in the Desktop file.

By the way, Gatekeeper Aid 1.0.2 has been in beta testing for months now.
If everything goes well with the testing of the latest beta, it could be
released in the next several weeks.  Sadly, though, I can't make any
guarantees.

I hope this helps,
- ----Chris (Johnson)
- ----Author of Gatekeeper
- [e-mail]

------------------------------

Date:    Sat, 16 Jun 90 18:40:00 -0400
From:    [e-mail]
Subject: GateKeeper Aid 'ADBS' Query (Mac)

Quote
"A member of our computing center uses GateKeeper Aid on her Macintosh IIcx
and has received the following message:

        GateKeeper Aid found an "Implied Loader 'ADBS' virus in the Desktop
        file on the "Animal Sanctuary" disk.  The virus was removed.
"

I think that all you need to do is to update Gatekeeper Aid to v. 1.0.1
The earlier v. did not like Adobe Separator's icon (and maybe some other
things).

- ----------------------------------
Richard Howland-Bolton
Manager Publications Computing
Cornell University
Internet: [e-mail]
Compuserve: 71041,2133
Voice: [phone]
FAX: [phone]
Etc, etc.
- ----------------------------------

------------------------------

Date:    17 Jun 90 16:27:05 +0000
From:    bnrgate!.bnr.ca![e-mail] (Henry Troup)
Subject: Re: Password Standards Checking

[e-mail] (Chuck Sechler) writes:
>Basically, we want to know if there has been any work on MVS and CMS platforms
,
>to keep users from picking obvious passwords, like their name, password same
>as userid, password is a word, etc. On MVS we are working on Top Secret

Under VM/SP (CMS) we use VMSECURE, which has a user exit facility that can be
and is used for this kind of checking.  It also stored password encrypted,
and keeps the last 'n' passwords to prevent reuse.  It also provides password
aging, proxy login, and a number of other nice features.

Disclaimer: no longer a system programmer, just a happy user...
- --
Henry Troup - BNR owns but does not share my opinions
..uunet!bnrgate!hwt%bwdlh490 or  [e-mail]

------------------------------

Date:    Mon, 18 Jun 90 11:46:38 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: F-PROT via FTP (PC)

I have been trying (unsuccessfully) to upload F-PROT to SIMTEL20, but
those of you wanting to obtain a copy of the package via FTP can get
it from chyde.uwasa.fi (128.214.12.3).  It can be found as
fprot110.zip in the "pc/virus" directory.

- -frisk

------------------------------

Date:    Mon, 18 Jun 90 10:07:00 -0400
From:    Dimitri Vulis <[e-mail]>
Subject: Help requested with a purported Yankee Doodle infection (PC)

Hello,

A little while ago I snailed some diskettes to a colleague in Poland.
He has just sent me e-mail saying that the executable files are infected
with the Yankee Doodle Virus. This is the first time I hear of this virus,
of course. :)

Since the files were PKZIPped before shipping, it's reasonable to conclude
that the machine they came from is also infected.

Questions:
1. Can someone refer me to a document, or a previous discussion on this news-
group, where this virus is discussed? What does it do?
2. Can someone please recommend a PD or shareware program for *scanning*
existing executable files for this speciaes of virus (and others, if possible).

Thanks,
Dimitri Vulis
Department of Mathematics
City University of New York Graduate Center

Administrator of RUSTEX-L, the Russian text processing mailing list

------------------------------

Date:    Sun, 17 Jun 90 22:21:07 +0200
From:    [e-mail] (Morton Swimmer)
Subject: Discussion: definitions of common computer beasts (ie. viruses..)

I haven't recieved as many definitions as I hoped, but I decided to
post the ones I recieved anyway.

============ This is how it started: ==============

[MS: I wrote...]

          I have been increasingly perplexed by the fact that there seems
to be little consensus on what the definition of the term
"Computer Virus" actually includes. This goes for other computer
"beasts" such as "Trojan Horses" and "Worms". I would be interrested
in hearing what other people think a virus is.

          Here are my own definitions:

Computer Virus: a non-autonomous program that has the ability to
copy itself onto a target.

Trojan Horse: an autonomous program that has a function unknown
(and unwanted) by the user.

Worm: a program or set of programs that have the ability to
propagate throughout a network of computers.

          Please note that both worm and virus definitions do not
include the possibility of a payload. This may or may not be a
weak point. Also note that the definitions of virus and trojan
differ greatly from how Cohen defines them. This is intentional
as I feel that Cohen's definition of virus is too broad (it can
include a normal program such as DISKCOPY!). I'm not happy with
my definition of worm myself. Also, (and this should be obvious)
none of my definitions are very formal.

[MS: with payload I meant a routine that does something unrelated
to the propagation of the virus or worm.]

=============
[MS: Padgett Peterson <[e-mail]>
wrote...]

          I agree with you completely & thing the whole question of
definitions is getting out of hand: the public is calling ANYTHING
out of the ordinary a virus and Dr. Tippett is not helping matters.

[MS: what did Dr. Tippett say?]

          To me, the primary difference between a virus and a worm is
that a virus is parasitical (cannot exist by itself) while worms are
stand-alone entities.

          To simplify things, I put together a list of seven elements of
malicious software. Not all will contain each but helps for classification:

1) Insertion   - The introduction of software to an environment.
2) Evasion     - Actions taken to avoid detection.
3) Mutation    - Adaptation to a system or environment.
4) Replication - The means for propagation.
5) Trigger     - Signal for change from covert to overt action.
6) Action      - The overt action.
7) Eradication - Removal of the infection following action.

          Further subclassifications would identify the particular type such
as for (4), type (a) might identify singular procreation (worms) while type
(b) might be parasites (viruses) .

          The DATACRIME virus for instance contained a code segment to permit the
initial version to be distributed as a standalone (4a) but which mutated
(3) into a parasite (4b) once exposed to executable files.

          For instance, only worms and viruses contain elements (3) and (4)
and differ only in method. Logic Bombs are characterized by having (2) & (6)
only. A trojan horse on the other hand may also contain (5).

          Obviously, all malicious software requires (1) but this may be treated
as a separate issue.

          I developed this list some time ago but have been reluctant to pulish
it as it is essentially a check-list for modular malicious software, however
in view of some other postings, this does not have further validity and may
help in understanding just what these constructs do.
[MS: thank you for posting it anyway. I feel that your checklist is not
precise enough. Or maybe I just haven't understood it fully.]
                              Padgett Peterson
arget: A program.

=============
[MS: Paul Shields <shields%nexus.yorku.ca@unido>
wrote...]

[MS: my own stuff deleted]
Ok, here is how I use the terms:

virus: a parasitic program capable of infecting (attaching
    itself to) other programs, so that it will be executed when the
    infected program is executed.

trojan horse: a program that appears to be another program
    in order to trick a person into executing it or upon executing it
    to reveal a secret, such as a password.

[MS: I would leave out the bit about the secret. It makes the definition
too specific]

worm: an autonomous program designed to "stay alive"
    by executing itself as many times as possible, possibly
    taking advantage of propagation through computer networks.

[MS: Hmm, I dont see how this definition defines anything. A virus tries
to "stay alive" by spreading as far as possible. In effect it is being
executed "as many times as possible". I always related worms to networks.]

[MS: the rest deleted. It was a comment on my use of the word "payload"]

============

[MS: Thomas E. Zmudzinski wrote...]

[MS: ...my posting deleted...]

    As the Japanese would say, a most honorable first attempt.  I'm afraid
that you're about to get zapped by the bane of lexicographers, accuracy vs.
depth of understanding.

[MS: I can protect myself with the shield of seniority. I've been dealing
with viruses for quite awhile.]

It's roughly analogous to the Completeness Theorem
in Mathematics.  If you define a set "A" and someone finds something that
should be a member outside of your definition, you need to expand your
definition.  If this is carried to extremes, you eventually have a very
long definition that can never be complete [see BLIVET below].

[MS: or else you use Occam's razor and reduce the definition to the
least common denominator. This is what I try to do without reaching to
the absurd: "Any routine is a virus".]

    First, I see a problem in tying your definitions for types of malicious
code to "program(s)".  There are other forms of "life" out there.  There are
BAT file viruses [see Ralf Burger's _COMPUTER_VIRUSES,_a_high-tech_disease_],
[MS: Ralf is an idiot. His ideas are rarely original. Many come from Cohen,
others from other Chaos Computer Club members.]
modem viruses, and other such critters that are not "programs" unless one
really stretches the definition.  My Random House dictionary says a program
is "a systematic plan for the automatic solution of a problem by a computer",
then turns around and defines a computer as "a mechanical or electronic
apparatus capable of carrying out repetitious and highly complex mathematical
operations at high speeds".  [I wonder what they would think of a PostScript
virus? :{D]

[MS: I don't see this necassarily to be a problem. A program is an executable
entity. It needs a platform to run on, be it the machine, the shell, BASIC
(dread the thought), or whatever. A good definition for a virus should be
independent of the platform.]

    Second, I won't buy your definition of a trojan horse as "an autonomous
program...".  A "trojan horse" *is* a "payload", not a "program".  A "trojan
horse program" is a program that contains a trojan horse, and "trojan horse
code" is somewhat redundant but designates the code segment that performs the
malicious operation(s).

[MS: I may need to capitulate on the term Trojan Horse. My definition rests
mostly on the analogy of the Trojan Horse as described by Homer in the Illiad.
It was a seemingly harmless object (the wooden horse) that fooled the
Trojans, but it contained a hidden (or covert) body of warriors. Unfortunately
many people have chosen to call the warriors the Trojan Horse. I am not sure
whether my definition is better, but it sticks closer to the analogy.]

                         [Want a real zinger?  Slip this trojan horse into
someone's AUTOEXEC.BAT, they will *NEVER* forgive you.

[MS: ...something ugly deleted...]

    My suggested definitions?  Well,...

    BLIVET (n) [Classically and empirically defined as "10 pounds of
           horsesh*t in a 5 pound bag"] Unrestricted use of a limited resource
           (e.g. spool space on a multiuser system).

    COMPUTER VIRUS (n) A self-replicating segment of executable instructions.

    PEST (n) A set of instructions that self-replicates uncontrollably,
           eventually rendering a network or system unusable via a blivet
           attack.

    PHAGE (n) An autonomous program that inserts malicious code into other
           autonomous programs (e.g. a computer worm or probe that carries a
           virus or trojan horse).

    PROBE (n) A non-self-replicating, autonomous program (or set of programs)
           that has the ability to execute indirectly through a network or
           multipartition computer system (e.g. various hacker utilities).

    TRAPDOOR (n) A method of bypassing a sequence of instructions, often
           some part of the security code (e.g. the computer logon).

    TROJAN HORSE (n) A segment of executable instructions hidden within an
           apparently useful program or command procedure that, when invoked,
           performs some unwanted function.

    WORM (n) A self-replicating, autonomous program (or set of programs) that
           has the ability to propagate through a network or multipartition
           computer system but does not insert.

[MS: ...the entertaining last bits deleted...sorry]

==========================================

There were not as many postings as I had expected. This may mean that
everyone is perfectly happy with my definitions. On the other hand,
many, like myself, are not so happy about them. In that case I will
still continue to collect definitions and summerize them. When I have
enough, perhaps we can finally get some consensus on the issue. We
will then have a sort of "VIRUS-L Standard Dictionary of computer
beasts". After all, where else can one get so many speciallist together?

I will also punch in other definitions that I have found on printed
media. I wanted to have done it by now, but an injury has prevented me
from carrying the books to university. By the next time I post I should
heve them.

Cheers, Morton

PS: I can be reached using these addresses:
          [e-mail]
          [e-mail]

------------------------------

Date:    18 Jun 90 16:22:00 +0100
From:    Norbert Hanke <dosman%cs.id.ethz.ch@cernvax>
Subject: FORM-Virus (PC)

One of our users just encountered a new boot sector virus which calls
itself FORM-Virus. It is not detected by SCANV63.

These are the symptoms:
  - the boot sector is replaced by virus code
  - 1k of bad block(s) is allocated

The first of those bad sectors contains near its end the text

        "The FORM-Virus sends greetings to everyone who's reading this
        text.FORM doesn't destroy data! Don't panic! Fuckings go to
        Corinne."

The second bad sector looks like the original boot sector.

Before we start further investigations: Did anyone of you see this virus
before?

Norbert Hanke
ETH Zurich

------------------------------

Date:    Mon, 18 Jun 90 11:55:53 -0400
From:    [e-mail] (William Clare Stewart)
Subject: Re: Password Standards Checking

[e-mail] (Chuck Sechler) writes:
]Basically, we want to know if there has been any work on MVS and CMS platforms
,
]to keep users from picking obvious passwords, like their name, password same
]as userid, password is a word, etc. On MVS we are working on Top Secret
]package, and it has some interesting capabilities for restriction, including
]generating random passwords, when a user if forced to change their password,
]but it is not ready yet. Some UNIX platforms check passwords against  very
]large lists of restricted words(like 50000 or more). Any thoughts? Should this
]be on a different list?

A good place to start would be misc.security, which is a moderated
newsgroup so I'm not crossposting this.  I don't know about MVS,
since I'm mainly a UNIX junkie, but a lot of the problems are common.

UNIX System V enforces a couple of checks: the password has to be at
least 6 characters long, including at least two non-alpha
characters, and can't contain the login name (or variants of it,
including cyclical permutaations and maybe spelled-backwards.)
Other systems (?BSD?) also check the password in /usr/dict/words
(the standard spelling dictionary on BSD).  If you want to implement
one of these, be careful that the password doesn't show up during
the run of the checking program (e.g. ps -ef shows
"grep secretword /usr/dict/words", or whatever equivalents MVS has.)

Newer systems designed for the government market, such as AT&T UNIX
System V/MLS (Which is B1-rated), implement the government
guidelines for machine-generated passwords, but there are mixed
opinions about how useful this is - assuming a good generation
algorithm which produces a large search space (>2**24), it's hard to
generate passwords that people won't write down on yellow-sticky-notes.
Smaller search spaces (e.g. 2**16, which is all too easy to get on
UNIX) are easily susceptible to brute-force search.
- --
                                        Thanks;  Bill
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Actually, it's *two* drummers, and we're not marching, we're *dancing*.
# But that's the general idea.

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 115]
******************************************
VIRUS-L Digest   Monday, 25 Jun 1990    Volume 3 : Issue 116

Today's Topics:

re: FORM-Virus (PC)
VSHIELD and WIN 3.0 (PC)
New files on MIBSRV (PC)
Re: Help requested with a purported Yankee Doodle infection (PC)
Warning - Flipper virus (Mac)
Re: UnVirus (PC); Public Domain
Re: Mainframe attacks (MVS)
Re: Mainframe attacks (MVS)
Re: Discussion: definitions of common computer beasts (ie. viruses..)
New files on MIBSRV (PC)
On Tippett's "Kinetics..."
Re: GateKeeper Aid 'ADBS' Query (Mac)
1704-virus (PC)
Anti-viral philosophies
Re: FORM virus (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    18 Jun 90 15:00:50 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: re: FORM-Virus (PC)

Norbert Hanke <dosman%cs.id.ethz.ch@cernvax>:
> One of our users just encountered a new boot sector virus which calls
> itself FORM-Virus. It is not detected by SCANV63.

We recently got a sample of that from Switzerland as well.  It infects
both floppy diskettes and the bootable partition of hard disks.  The
only side-effect I've found is that it will cause the speaker to click
while typing under some circumstances.  Usual disclaimers, of course;
what you've seen may not be the same virus that I've seen!
DC

------------------------------

Date:    Mon, 18 Jun 90 17:02:00 -0400
From:    [e-mail]
Subject: VSHIELD and WIN 3.0 (PC)

I have not encountered any difficulty in running the two together.
VSHIELD is loaded at the beginning of my autoexec.bat and subsequently
I load WIN 3.0 from a menu.  If anybody does have problems with this
or a different configuration, I'd also like to hear about it.

        Bogdan KARASEK

        [e-mail]

------------------------------

Date:    Mon, 18 Jun 90 11:51:04 -0500
From:    James Ford <[e-mail]>
Subject: New files on MIBSRV (PC)

The following files have been placed on MIBSRV.MIB.ENG.UA.EDU (130.160.20.80)
for anonymous FTPing in the directory pub/ibm-antivirus:

chkup39.zip  -  CheckUp V3.9
netsc63b.zip -  McAfee's NetScan program V63B. (taken from Homebase)
vcopy63.zip  -  McAfee's VCOPY program V63.    (taken from Homebase)
secur109.zip -  SECURE V1.09, tsr that prevents all known and unknown viruses.
                (*NOTE: Description taken from SECURE.DOC.  I have no knowledge
                       of the program myself....JF)
vtac42.zip   -  PC environment security program.

If you do not have FTP ability at your BITNET site, send a one line mail
message HELP to BITFTP@PUCC.
- ----------
He who never sticks out neck, never wins by nose.
- ----------
James Ford -  [e-mail], [e-mail]
              THE University of Alabama (in Tuscaloosa, Alabama  USA)


------------------------------

Date:    19 Jun 90 08:58:54 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Help requested with a purported Yankee Doodle infection (PC)

[e-mail] (Dimitri Vulis) writes:
>1. Can someone refer me to a document, or a previous discussion on this news-
>group, where this virus is discussed? What does it do?

There are actually two different virus groups called "Yankee Doodle".  Both are
from Bulgaria, but they are different in several ways.

    Group 1: "Old Yankee" infects only .EXE files. When an infected program is
    run, the virus does a full-depth recursive search on the current directory,
    until a non-infected file is found, which will then be infected. The
    virus then plays the Yankee Doodle tune and transfers control to the
    original program. It does not remain resident in memory.  Infected
    files are marked by placing the word "motherfucker" at the end.
    Two variants are known one 1961 byte and another, shorter one, only 1621
    bytes, which does not play the tune - it does nothing but replicate. More
    variants are expected in the future, as the author has distributed the
    source to the virus.

    Group 2: TP's "Yankee Doodle".  Versions 26-44+ of the TP series of
    viruses (which includes the "Vacsina" viruses as well) also play Yankee
    Doodle.  Versions 26-32 play it when Atrl-Alt-Del is pressed, 33-43 play
    it at 5pm, but versions 44- have only a 1-in8 chance of playing it at that
    time.  Those viruses are resident, and quite a bit longer than the other
    ones 2-3.5K

Compared to many other viruses, the "Yankee-Doodle" viruses are fairly
harmless, but nevertheless a problem.

>2. Can someone please recommend a PD or shareware program for *scanning*
>existing executable files for this speciaes of virus (and others, if possible)
.

Three program that can (I think) find all the known variants

    VIRSCAN  from IBM
    SCAN     from McAfee
    F-PROT   my own - which can remove them all as well :-)

- -frisk

- --
Fridrik Skulason      University of Iceland  |
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: [e-mail]    Fax: [phone]  |

------------------------------

Date:    19 Jun 90 10:51:23 +0000
From:    [e-mail]
Subject: Warning - Flipper virus (Mac)

A virus known as "FLIPPER" has 'woken up' on the Apple Mac in the Arts.  It was
removed by Disinfectant in early June, but it is possible it is still on some
user disks.  Please check yours using Disinfectant!

------------------------------

Date:    Wed, 20 Jun 90 15:07:52 +0300
From:    Y. Radai <[e-mail]>
Subject: Re: UnVirus (PC); Public Domain

  David Chess asks:
>If you don't consider it proprietary, I'd be curious to know what
>the scanning algorithm is that it doesn't slow down as the number
>of viruses increases.

A word to the wise is sufficient, isn't it?  Well, the word in this
case is "hashing" ....

  BTW, the implementation of the new UnVirus has since been speeded up
so that it's now almost 4 times as fast as SCAN.


  I was also asked in a personal letter what I meant when I wrote in
the same posting:
>       *freeware* (often erroneously called "public domain" software).

Since "public domain" is a legal term, some of what I'm about to write
may not be entirely accurate, but I think my conclusion will still be
valid.  As I understand it, "public domain" means (at least approxi-
mately) *not copyrighted*.  Previous postings here on copyrighting
have indicated that a program written after 1 Mar 89 (the date the
U.S. became a signatory to the Berne Convention) is automatically
copyrighted at the moment of creation, without need for a copyright
notice.  It therefore seems to me that a program written after this
date (in the U.S.) can be PD only if its author explicitly states that
he releases it to the public domain or that he waives all his rights.
And such cases constitute only a very small portion of the programs
available on most so-called "PD" servers, even if we restrict our-
selves to freeware.
  True, a program written before 1 Mar 89 is not copyrighted unless it
bears a copyright notice of the form "Copyright year name", and many
authors thought they could write "(C)" instead of "Copyright", which
is incorrect.  So maybe such programs would be considered PD if such a
matter ever came to court.  In any case, the *concept* or *definition*
of "public domain" is very different from that of "freeware", and
that's all I was claiming.

  Disclaimer: I have no legal background; if anyone with such a back-
ground finds an error in what I've written, I shall repent.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     [e-mail]

------------------------------

Date:    20 Jun 90 19:42:55 +0000
From:    [e-mail] (Chuck Hoffman)
Subject: Re: Mainframe attacks (MVS)

[e-mail] (Tony Harminc) writes:
> I think mainframe hacking was much more popular in those days simply
> because mainframes were all there were.

   That also was about two years before the time that the Security group
at SHARE formed, which developed the specifications for the product which
became ACF2 in 1978.  Simultaneously, IBM was secretly developing RACF.
By the early 80's, ACF2 was beginning to dominate the MVS system security
market, and it became much more difficult for hackers who were not in the
systems programming groups to make significant intrusions into MVS
systems.  RACF was slow to develop because, in many people's opinions, it
was conceptually a poor design.  These days, though, many MVS sites do use
it.
   It is true that some of the architectural features of the original MVS
still exist in MVS/XA, making it possible to obtain system privileges.
Those who have been involved with MVS systems programming over the years
know the features well.  But on systems which are routinely managed by
ACF2, TopSecret, or RACF, it is very difficult for a person outside the
systems programming group to exploit those features.  There also are
extensive auditing tools and methods for monitoring systems, and, unlike
micros, MVS systems generally do not update or upgrade themselves while
they are running.  It is still possible, but unlikely.  With 15 years on
MVS systems in many companies, 10 on ACF2 and RACF protected systems, I
personally have never heard of a case of an unauthorized system update
caused by someone outside the systems programming group.  I'm sure they're
there, but if they were common, I guess I would have heard about a few
through one of my employers, or through my consulting business, or through
the ACF2 conventions, through SHARE, or through the regional ACF2 user's
group I was heavily involved with.  I didn't.
   Things are about to become tighter, too.  Computer Associates is in the
process of raising the rating of ACF2 and Top Secret from C2 to B1.
   On Digital VAXs, the VMS system technically is C2, but in my opinion
the architecture is so cumbersome that systems managers have some
justification when they say that you need system privileges all the time
just to do a job.  Yes, it's C2, but so many people end up with privileges
that it hardly matters.
- -Chuck


- - Chuck Hoffman, GTE Laboratories, Inc.
[e-mail]
Telephone (U.S.A.) 617-466-2131
GTE VoiceNet: 679-2131
GTE Telemail: C.HOFFMAN

------------------------------

Date:    21 Jun 90 03:49:45 +0000
From:    [e-mail] (Woody Baker @ Eagle Signal)
Subject: Re: Mainframe attacks (MVS)

While we are talking mainframe attacks, way back in 1976 or so, some
of my crowd of hackers, discovered that if you ran a program that upped
your privlege level temporarily in order to run (there were several), then
hit CTRL and BREAK backand forth several times rapidly, the os would get
confused.  Then when you exited your session, your account table was dumped
back to disk with the result that when you logged on again, you had A0
(system administrator) privelege, and could do anything you jolly well
pleased.  The hole was plugged within a couple of days, but I understand
that certain other accounts were created in the mean time that allowed
unfettered access to the machine.
I once had a psychology prof, who imparted a real jewel to the class.
"Things take more time than they do"  A paraphrase of that:
"Operating systems are as secure as they are.

Cheers
Woody
The above attack was made on CP-V on a Xerox Sigma 6 or 7.

------------------------------

Date:    Thu, 21 Jun 90 11:27:56 +0000
From:    [e-mail] (Jerry Anderson)
Subject: Re: Discussion: definitions of common computer beasts (ie. viruses..)

Here are my definitions of virus, worm and Trojan horse:

    virus        - a dependent self-replicating program.

    worm         - an independent self-replicating program.

    Trojan horse - a program with a hidden agenda.

By dependent, I mean that a virus "lives" within another program.

I do not believe that the definition of a worm has anything to do with
networks.  I think that association has risen due to the infamy of the
Internet worm.

I took the definition for a Trojan horse directly from Maarten Van Swaay.
I also think that a Trojan horse is the program that carries the
"payload," not the payload itself.  (Remember, the Trojan horse of
literature *contained* the suprise.)

When describing virii, worms, etc, many people end up by saying something
like "... and does something bad, like erase your files."  Granted, the
people who create these things and set them loose quite often put in
something nasty, but that isn't really part of what they are.  It is simply
how they are used.  If someone writes a program with a beneficial hidden
agenda, the program is still a Trojan horse.
- --
I like girls - German girls.                      Jerry J. Anderson
                                                  Computing Activities
BITNET:   jerry@ksuvm                             Kansas State University
Internet: [e-mail]                     Manhattan, KS  66506

------------------------------

Date:    Thu, 21 Jun 90 08:26:31 -0500
From:    James Ford <[e-mail]>
Subject: New files on MIBSRV (PC)

The following files have been placed on MIBSRV.MIB.ENG.UA.EDU (130.160.20.80)
in the directory pub/ibm-antivirus for anonymous FTPing.

fprot110.zip  -  FProtect
vsum9006.zip  -  Virus Summary Listing (current as of June 1990)

(Thanks to Jim Wright for sending FPROT110 to me......)
- ----------
    James Ford - [e-mail], [e-mail]

------------------------------

Date:    21 Jun 90 15:42:17 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: On Tippett's "Kinetics..."

Various people have mentioned Dr. Peter Tippett's paper "The Kinetics
of Computer Virus Replication" here recently.  We wrote a brief reply
to the paper awhile back, and I thought it might be reasonable to post
it.  This isn't an Official IBM Statement or anything like that, just
the reaction of the researchers here at the High Integrity Computing
lab.  (I don't know how people in general can get a copy of the paper
itself, I'm afraid.  I don't know whether it's been formally published
anywhere; the copy we have was apparently handed out at a press
conference.)

     The conclusions in Dr. Tippett's paper are based on a very
simple model of uncontrolled, exponential growth.  We are not
convinced that the assumptions or conclusions of the paper are
correct, and they do not seem to be supported by the actual data
available to us.  The model neglects several effects that we think
are crucial to understanding virus spread.  We think substantially
more work in modelling virus spread will be required before it's
possible to make valid quantitative predictions.

     Tippett's analogy with runaway biological growth neglects the
paths along which programs are shared (the "sharing topology"), and
incorrectly models the effects of widespread scanning on virus
growth.  Our own preliminary studies of very crude models which
incorporate program sharing and scanning indicate that, under
certain conditions, the fraction of infected machines can stabilize
at a much lower value than Tippett suggests ( < 1% in some cases).
Furthermore, if the scanning rate for a known virus were sufficiently
high, the exponential growth of the virus population predicted by
Tippett would reverse, and the virus would eventually become
extinct.  This is in contradiction to Tippett's conclusion that
scanning is ineffectual.  (To anyone interested in looking into some
good work on modelling the spread of biological viruses, we'd
suggest consulting recent issues of the journal "Mathematical
Biosciences".)

     Our own data on virus incidents do not show any trend towards
explosive growth, neither for viruses in general nor for the 1813
and Brain viruses which Tippett discusses.  We would be very
interested in seeing other reliable data on virus populations as a
function of time.

     We are rather confused at Tippett's assertion that "systems
management software" can contribute to real improvement in the
problem, whereas other methods cannot.  No evidence is presented for
this in the paper, and it would appear that the same analysis that
is used to claim that scanning is ineffective could be applied to
virtually any other method of reducing the virus population,
including the use of systems management software.

     We believe that, in order to make reasonable predictions about
the population dynamics of computer viruses, we need to formulate
more realistic models which incorporate some aspects of the virtual
and physical connectedness of the world's computers and at least a
minimal understanding of human habits.  The analysis and interpretation
of such a model will not be easy, but the success that mathematical
epidemiologists have achieved in understanding the spread of some
infectious diseases encourages us to think that we will be able to
do it.

DC

------------------------------

Date:    Thu, 21 Jun 90 17:47:00 +0700
From:    [e-mail] (Jon W{tte - SoftWare konsult)
Subject: Re: GateKeeper Aid 'ADBS' Query (Mac)

Maybe the ADBS weren't where it belonged, or was patched to load
another resuorce. (an ADBS is a driver routine for the Apple Desktop
Bus, if memory serves me right)

Just a guess...

------------------------------

Date:    Fri, 22 Jun 90 10:05:12 -0400
From:    9991@db0tuz01
Subject: 1704-virus (PC)

We got a virus problem at our site (FU-Berlin, Neurobiology): several
of our AT's got a virus infection. It's very likely that we have the
old 1704 virus or one of its children with the same head.  Does
anybody know of a way how to get rid of this virus (without erasing
all infected *.COM files)? It seems the virus knows of the old start
address of the program but where the hell does he hide it?  Any
advises or recommondations are welcome.

Thanks in advance

E.Lieke.

------------------------------

Date:    22 Jun 90 13:32:33 -0400
From:    Bob Bosen <[e-mail]>
Subject: Anti-viral philosophies

>>   Like to get some opinions on this one. If you could only get
>>one program for your pc/pc-xt/pc-at or clone, what would it be?

> This is a question that keeps coming up and while I agree that
>McAfee's products are the best for someone who knows what they
>are doing, they are not products that are suitable for environments
>with vast numbers of PCs and semi-educated users...
>
> 1- Can you imagine trying to install monthly updates on 5000 PCs...
>....
> What I perfer is a package that resides in the background of the
> user's PC and reports any change to the environment with no
> appreciable hit to performance

My thanks to Padgett for so clearly expressing what I have been unable
to say on this forum. As a vendor, it's hard for me to come here and
initiate discussions about my own products. Be warned: I am speaking
about my own commercial product here.

Our "SafeWord VIRUS-Safe" performs exactly as Padgett describes above.
It was designed with EXACTLY this kind of situation in mind. It also
maintaines a detailed log of changes to files so a virus researcher
can figure out what kind of virus may have been polluting things. The
log reveals the date and time of detected changes, before-and-after
signatures using any industry-standard signature algorithms, length
changes, etc. If That's what you are looking for, please give me a
message.

Bob Bosen
Enigma Logic
USA tel: [phone]
Bob Bosen

------------------------------

Date:    Sat, 23 Jun 90 20:01:14 +0200
From:    [e-mail] (Morton Swimmer)
Subject: Re: FORM virus (PC)

I'm sorry I didn't post this before, but the way things are at
the moment, I rarely get to eat.

The Form virus is a Swiss product. It has apparently infected
most of the schools in canton Zug so I'm not surprised that
you have got it at ETH Zuerich.

To make it short: it is indeed a boot sector virus. It will
infect floppies as well as hard disks. It has a damage: on
every 24th of any month it will make the keys click, but
it doesn't seem to work on my machine. Otherwise it is not
destructive. It is well programmed, and doesn't seem to have
been derived directly from any other virus. Normally it
should not bother you.

I had promised an antivirus for it, but time didn't allow it.
Like most boot sector viruses, it can be removed (or at least
deactivated) by booting from a _clean_ disk and using the SYS
command to overwrite the virus boot sector.

Cheers, Morton
Virus Test Center

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 116]
******************************************
VIRUS-L Digest   Wednesday, 27 Jun 1990    Volume 3 : Issue 117

Today's Topics:

Virus experiences in GDR
"Virus" on MS-DOS systems (PC)
fprot111.zip (PC)
STONED Virus (PC)
More info on the "Flipper" virus (Mac)
ZUC info anyone (mac)?
Possible new WDEF Strain (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    22 Jun 90 15:42:00 +0100
From:    Klaus Brunnstein <[e-mail]>
Subject: Virus experiences in GDR

On June 19-21, 1990, IBM held some kind of a development conference for GDR
universities, in the research center of the ministry for science and technology
in (east) Berlin-Koepenick. Similar to an annual conference for West German
universities (`IBM university forum'), invited speakers from West and East
German universities as well as from IBM informed about their actual work. A
broad diversity of areas was covered, from CD-ROM based 'Thesaurus Linguae
Graecae' to CAD, simulation of complex molecules and synthetic speech. The
conference was accompanied by an exhibition where many additional applications
and software products of scientific interest were shown by East and West German
scientiests as well as IBM people, on IBM owned PS-2s. Many demonstration
diskettes were freely available.

Among the exhibitors, the Virus Test Center demonstrated how to detect and
eradicate viruses. In many discussions, we were surprised to learn that
many scientists regarded viruses as some kind of a joke as they had suffered
mainly from viruses of the funny kind, e.g. playing Yankee Doodle in the Bulga-
rian version "TP 44" or "legalizing marijuana"; only a few seemed to have
experiences in really damaging viruses such as Israeli or Dark Avenger. Yet at
the end of the exposition, our essential task was to eradicate some damaging
viruses such as Dark Avenger (the Bulgarian "Eddie" which broadly migrates
through Eastern Europe) from most of IBM's PS-2 as neither protection
nor careful work had been practized nor prescribed.

With surprise we learned that there existed a secret research unit in GDR
to which every virus or other threat had to be reported; this secret group
would then produce an antivirus and send it to concerned institutions. In its
latest version (which we hope to receive afterwards), 11 viruses could be
detected and eradicated.

Lesson learned: there should be a special antivirus service for exhibitions,
not only for large ones (in FRG's CeBIT and Systems exhibitions, about 15-20%
of the workstations and PCs were found to be infected *at exhibition's end*).

Klaus Brunnstein       University of Hamburg

------------------------------

Date:    Mon, 25 Jun 90 15:25:00 -0400
From:    Meredith Coombs <[e-mail]>
Subject: "Virus" on MS-DOS systems (PC)

We've come across a virus-like problem which seems to primarily
affect floppy disks.   It shows up when you try to format a floppy
and get an error message that says the boot sector is bad.  Attempting
to use the FORMAT command on a pc's hard disk when the system has the
"virus" results in an error message.  (You can do an FDISK -- from
a floppy -- of the hard disk.)

One way the "virus" makes itself known is by creating a file
named delta-character4EIBM.n.n or delta-char<EIBM.n.n  (where n.n
stands for the DOS version with which the diskette was formatted.

I'd appreciate hearing from anyone who has information on cause and
cure for this virus.   (Our virus detecting software, SCAN v6.3 from
McAfee) can't spot it at all.)

Meredith Coombs
Manager of User Services
Stevens Institute of Technology
Hoboken, NJ  07030

------------------------------

Date:    Mon, 25 Jun 90 20:25:53 +0000
From:    [e-mail] (Harri Valkama LAKE)
Subject: fprot111.zip (PC)

Fridrik Skulason has uploaded his latest version of F-PROT (heavy
package of virus protection utils) to chyde.uwasa.fi (128.214.12.3)
It can be found in pc/virus directory and it is called fprot111.zip
- --
===== Harri Valkama ([e-mail], [e-mail], [e-mail]) =======
| University of Vaasa, PO BOX 700, 65101 VAASA, Finland (fax: [phone]) |
|      Moderating ftp site chyde.uwasa.fi (128.214.12.3) PC directory         |
=== and ftp site funic.funet.fi (128.214.6.100) Atari ST & Mac directories ====

------------------------------

Date:    26 Jun 90 13:57:53 +0000
From:    [e-mail] (Michael Lorengo)
Subject: STONED Virus (PC)

Posting For A Friend Who Cannot Do So------

- -------------------------------------------------------------
We have been hit with a
STONED virus on our hard drive Z-248's.  Unfortunately I
didn't grab any of the stoned info when it was available and
I wondered if you'd post the following for me?

We here at WMU are getting hit with the STONED virus in our
labs.  Please e-mail any info you have on how you have handled
this virus in your labs to:

     [e-mail]

Thank you.
- ---------------------------------------------------------------

I appreciate your consideration.  Thank you.

------------------------------

Date:    Tue, 26 Jun 90 12:00:00 -0400
From:    <[e-mail]>
Subject: More info on the "Flipper" virus (Mac)

        Can anyone please give me some more information on the
"Flipper" virus on the Mac?  I have not heard of this virus, and I am
curious to know what it does, where it was found, etc.  All help would
be greatly appreciated.

Melissa Jehnings
Wheaton College
Norton, Massachussetts
BITNET: JEHNINGS@WHEATNMA

------------------------------

Date:    Tue, 26 Jun 90 16:43:00 -0400
From:    Zav <[e-mail]>
Subject: ZUC info anyone (mac)?

    !-> I survived Southeastern Mass Uuu., 26-JUN-1990

    HEllo, I am wondering if anyone out on the net has any experience/tech
info regarding ZUC infections.  What does the resource fork of an infected
app look like??  While scanning our servers with SAM 2.0, 2 files from the
Mac tutor sources were listed as being infected in 2/5/88 and 5/24/88
(PopMenus and Color Mixer).  After copying them to a floppy, I scanned with
Sam 2.0 again, Rival 1.1 and Disinfectant 1.8 with no reported infections.
?!*?! HUH?  What gives?  If anyone cares I was in multifinder (I know, I
know) while scanning for the second time.  any clues anyone?

                                   - Alex Zavatone - Software Release Engineer
                                     PCSD Mac - Lotus

------------------------------

Date:    Wed, 27 Jun 90 11:26:00 -0400
From:    Zav <[e-mail]>
Subject: Possible new WDEF Strain (Mac)

    !-> I survived Southeastern Mass Uuu., 27-JUN-1990

    While scanning our servers, SAM 2.0 reported discovering a "strain of
WDEF".  Upon examination under resedit 2.0a3 the size and code was
completely different from the copy of WDEF A that I have.  Scans with
Disinfectant 1.8 and Rival do not pick this up as a virus.  Paul Cozza,
John Norstadt would you be interested in checking this file out?  It's
binhexed and ready to be sent out.

                                   - Alex Zavatone - Software Release Engineer
                                     PCSD Mac - Lotus

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 117]
******************************************
VIRUS-L Digest   Friday, 29 Jun 1990    Volume 3 : Issue 118

Today's Topics:

I'm bummed. (re BITFTP access to Scandanavia)
query - virus software licensing
The Worm That Turned
Warning - Jerusalem B from mail-order company. (PC)
Mainframe attacks
F-FCHK.ZIP update (PC)
Hacking
Virus on Startup Screen? (MAC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 27 Jun 90 17:07:32
From:    <[e-mail]> (Steven W. Smith)
Subject: I'm bummed. (re BITFTP access to Scandanavia)

Hello, all. After seeing the following:

  > From:    [e-mail] (Harri Valkama LAKE)
  > Subject: fprot111.zip (PC)
  > Fridrik Skulason has uploaded his latest version of F-PROT (heavy
  > package of virus protection utils) to chyde.uwasa.fi (128.214.12.3)

I tried to access chyde.uwasa.fi via [e-mail] and received not
fprot111.zip, but:

  > 19:50:36 > FTP chyde.uwasa.fi UUENCODE
  > 19:50:36 > USER anonymous
  > 19:50:36 >>>> Access to the Scandinavian nodes has been
  > 19:50:36 >>>> discontinued, due to the slowness
  > 19:50:36 >>>> and unreliability of the network connections.
  > 19:50:36 >>>> Please try to confine your BITFTP requests
  > 19:50:37 >>>> to North American nodes.  Thank you.

Any suggestions? Maybe a North American site with fprot111.zip, although I'd
prefer an alternative to BITFTP (short of going Unix, that is)...
Many thanks
  _,_/|
  \o.O;   Steven W. Smith, Programmer/Analyst
 =(___)=  Glendale Community College, Glendale Az. USA
    U     [e-mail]

------------------------------

Date:    27 Jun 90 14:30:22 +0000
From:    [e-mail] (Jon Alexander)
Subject: query - virus software licensing

In the Macintosh world, we have available a number of
anti-virus software utilties that are free or minimal in
cost (e.g. Disinfectant, GateKeeper programs).

In the PC-DOS and compatible world, we have found no such
software. (Note: we have downloaded a copy of F-PROT,
but we have no experience with it, and we've seen very
little discussion of it, up to now).

We are currently looking at several options, including
a SITE LICENCE for the McAfee suite of anti-virus
tools. To all readers: Does your organization have
any experience with site-licensing PC anti-virus
software?

Specifically, we are wondering how much hassle
sites have encountered with administering this
kind of licence.

Jon Alexander
University of Toronto Computing Services
Toronto, Ontario, CANADA
PHONE:  [phone]
E-MAIL: [e-mail]

------------------------------

Date:    Thu, 28 Jun 90 12:12:37 +0100
From:    [e-mail]
Subject: The Worm That Turned

Article in the UK magazine Personal Computer World July 1990 p.202-206
"The Worm That Turned" by Ian Witten and Harold Thimbleton.
Describes how they have utilised the same mechanism that a virus employs to
spread itself to create dtabases that automatically update themselves.
They call their software "liveware."
Some definitions:
Liveware - a hypertext (or other) database that updates itself automatically
whenever the occasion arises.
Enliven - to innoculate a person's computer with a Liveware information owner
an owner of one or more cards in the database, and the only person permitted
to change them.
Database owner - the person responsible for the Liveware database as a whole.
They are not empowered to alter information belonging to others.
Signature - a code identifying an owner including their full name and perhaps
an encrypted secret password that only they can generate.
Livestamp - the Liveware information recorded on each card; signature
information and time stamp.
Merge - the joining of two Liveware databases together so that both contain
the most recent information.
Thimbleby works at Stirling University, Scotland.
Witten is with the Department of Computer Science, University of Calgary,
Canada.
Rgds,
Iain Noble
Teesside Polytechnic Library, UK
- -----------------------------------------------------------------------------
Iain Noble                                   |
[e-mail]                           |  Post:  Main Site Library,
JANET: [e-mail]                    |         Teesside Polytechnic,
EARN/BITNET: LBA002%pa.tp.ac.uk@UKACRL       |         Middlesbrough,
INTERNET: [e-mail] |         Cleveland, UK, TS1 3BA
UUCP: [e-mail]            |  Phone: [phone] x 4371
- -----------------------------------------------------------------------------

------------------------------

Date:    Thu, 28 Jun 90 02:50:00 -0400
From:    [e-mail]
Subject: Warning - Jerusalem B from mail-order company. (PC)

I'm new to this group, but I thought I'd put the word out so others don't get
their computers infected.  I recently bought a I/O - floppy drive controller
card (SUPER MULTI I/O)  from Jems Computers in San Jose, California.  Along
with it came a floppy with the setup programs for the clock/cal.  It turns out
that it was infected with the Jerusalm-B virus.  Unfortunately, I didn't find
out until it had infected about 40% of my .EXE and .COM files.  I called them
and they said that the disk came with the card from the manufactuer.  I would
be VERY careful with any software that comes from there...mind you I'm not
saying not to buy from there (the card and the 1.44M drive I recieved are
excellent) but just check out the software extra carefully.  We now return you
to the regularly scheduled programming.
                                                                             FF
*******************************************************************************
A. Poulias *"And you run and you run to catch up with the sun, but it's sinking
MIAMI U.   * And racing around to come up behind you again
Oxford, OH * The sun is the same in the relative way, but you're older
           * Shorter of breath and one day closer to death
           **************         - Pink Floyd Time - The Dark Side of the Moon
[e-mail] *
[e-mail]  *******************************************************
*************************

        B-T-W, I was able to remove the virus with CLEANUP from McAffee
Associates.  If anyone from there is reading this, my registration is on
the way.

------------------------------

Date:    Thu, 28 Jun 90 14:17:05 -0500
From:    [e-mail] (Emily H. Lonsford)
Subject: Mainframe attacks

Chuck Hoffman of GTE Laboratories, Inc., writes:

"   That also was about two years before the time that the Security group at
SHARE formed, which developed the specifications for the product which became
ACF2 in 1978.  Simultaneously, IBM was secretly developing RACF."

My recollection is that RACF came before ACF2.  David Chess can probably
clarify the exact date.  Barry Schrager of SKK (the original developers of
ACF2) was a member of the SHARE committee that wrote the first security white
paper, on what an access control system should do.  IBM's response, RACF, fell
far short of the mark - for one thing, in early releases it protected BY
EXCEPTION rather than BY DEFAULT.  SKK decided they could do a better job, and
went off and wrote ACF2 on London Life's computer in Toronto.  I did a survey
of the two packages in the 78-79 time frame and ended up choosing ACF2 for my
employer, an energy company.

"it became much more difficult for hackers who were not in the systems
programming groups to make significant intrusions into MVS systems. "

I think you meant to say that it requires knowledge of MVS.  True, the
controls are there with ACF2, RACF and TopSecret to prevent non-sysprogs from
hacking into MVS.  but how _well_ are they implemented?  All it takes is one
privileged ID with a trivial password, or one unprotected APF library,
installation ID with the default password, etc. etc.

And you have to be cautious about the sysprogs.  They have the knowledge and
the power to do lots of damage, just by accident.

"Computer Associates is in the process of raising the rating of ACF2 and Top
Secret from C2 to B1."

Is that what CA is telling you?  I just looked in my April 1990 "Information
Systems Security Products and Services Catalog", a government publication, and
CA is not in the list of vendors in the evaluation process.  The process
normally takes at least 2 years.  Interestingly enough, IBM _is_ listed in the
evaluation process for MVS-ESA/RACF, aiming at a B level evaluation.
Currently MVS/XA with RACF, ACF2 or TopSecret is rated at C2.  You might want
to get a copy of the catalog from your local GPO Bookstore.  It has some
interesting information in it about lots of security products.

And just because the OS is evaluated at B1 doesn't mean _in your implemen-
tation_ that it's B1 secure.  For one thing, any OS modifications (SVCs exits
etc.) invalidate the rating. Can you imagine MVS without add-ons?

"On Digital VAXs, the VMS system technically is C2, but in my opinion the
architecture is so cumbersome that systems managers have somejustification
when they say that you need system privileges all the time just to do a job.
Yes, it's C2, but so many people end up with privileges that it hardly
matters."

I agree that it's difficult to manage the privileges on VAX/VMS.  But at least
DEC included C2 level protection in the OS, rather than making the user buy an
ADD-ON package to get security.  Let's face it:  without ACF2, RACF or
TopSecret, "MVS security" is an oxymoron.

To me, the worst problem is with UNIX's root account; there it's all or
nothing when it comes to privileges.  There's no such thing as "separation of
duties."  And so far the "more secure" versions of UNIX really haven't
addressed that.

As always, my opinions are my own, not necessarily those of my employer.
*        Emily H. Lonsford
*        MITRE - Houston W123  [phone]

------------------------------

Date:    Thu, 28 Jun 90 13:05:25 -0500
From:    James Ford <[e-mail]>
Subject: F-FCHK.ZIP update (PC)

An update to FProtects F-FCHK has been added to MIBSRV.MIB.ENG.UA.EDU
(130.160.20.80) in the directory pub/ibm-antivirus.  (again, thanks to
Jim Wright).

FPROT110.ZIP - Origional ZIP file of FProtect
F-FCHK.ZIP - one file (f-fchk.exe)

FPROT110A.ZIP - FProtect package with updated F-FCHK.EXE file.  Note
                that the name is *not* standard DOS (9 characters
                instead of 8).  - ( I don't think this will be a problem
                but if it is, then let me know..JF) -
- ----------
Life is what goes by while you are watching television.
- ----------
James Ford -  [e-mail], [e-mail]
              THE University of Alabama (in Tuscaloosa, Alabama  USA)

------------------------------

Date:    29 Jun 90 12:21:22 +0100
From:    [e-mail]
Subject: Hacking

Hi, I'm a PhD student doing a thesis on the phenomena of hacking and viruses
I'd really appreciate any information that people come across that might be
of use to me,especially stuff from "The Whole Earth Review" and "2600" which
I'm having difficulty getting access to here in the U.K.. Please E-mail me
or my postal address is, The Politics Dept., 31 Buccleuch Place, Edinburgh,
EH8 9JT. Thanks very much in advance,
Paul A.Taylor.

------------------------------

Date:    Thu, 28 Jun 90 16:48:11 -0400
From:    [e-mail] (Bruce Barnett)
Subject: Virus on Startup Screen? (MAC)

We have been having problems with MacIIci and Microsoft mail.
I suspect a new type of virus.

The Mac crashes when clicking "SETUP" in the chooser when selecting
          a mail server.
The Mac also crashes when opening the Microsoft Mail DA.

I have replaced the entire system folder, and re-installed TOPS, etc.

If I put back the start-up screen in the system folder, Microsoft
Mail crashes. (System error 12, or the screen freezes.)
When I move the start-up screen to a new place and
restart the Mac, everything works fine.

This is repeatable. The start-up screen seems to be infected.

This problem has happened on several new Mac's (all MacIIci's)
in far ends of the building.  OS 6.0.4 and 6.0.5.
But not every MacIIci crashes.

I haven't narrowed it down to an exact combination of what must be
replaced when this crash occurs. But replacing (not updating) the
system, re-installing TOP and Microsoft mail, and deleting the
start-up screen seem like the best solution we have right now.

This corrupted "system" problem has been ten times harder to fix
than any virus we have seen. We use SAM 2.0 and Disinfectant 1.8, and
they find nothing wrong with the startup screen.

Can the startup screen contain a virus?

- --
Bruce G. Barnett    [e-mail]  uunet!crdgw1!barnett

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 118]
******************************************
VIRUS-L Digest   Wednesday,  1 Aug 1990    Volume 3 : Issue 136

Today's Topics:

re: Multi-platform virus scanning
re: other ways for viral injection?
mac disk locking (Mac)
Stoned Remover (PC)
Back issues now available in indexed/digested format
Site licenses
Joshi-B Infection Alert (PC)
Periodic virus sighting report

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 30 Jul 90 15:51:30 -0400
From:    attcan!vpk1![e-mail]
Subject: re: Multi-platform virus scanning

Paul,
          Most virus scanning software does simple pattern matching
of an existing 'known-virus' database against any files that you 'scan'.
If you have a list of viruses for the machine in question, it shouldn't
matter what platform you do the actual scan on. I have successfully
used a product called CERTUS in the exact manner that you described in
your letter. I simply defined a database for each platform and then
did the comparisons with the appropriate database based on the software
extension.


____________________________________________________________________________
        ===
      =--====  AT&T Canada Inc.             John Benfield
     =----==== 3650 Victoria Park Ave.      Network Support Analyst (MIS)
     =----==== Suite 800
     ==--===== Willowdale, Ontario          attmail   : ~jbenfield
      =======  M2H-3P7                                email     : uunet!attcan!john
        ===    [phone]               Compu$erve: 72137,722

____"Sometimes it just happens...People explode...Natural causes."__________

------------------------------

Date:    Mon, 30 Jul 90 16:14:35 -0400
From:    attcan!vpk1![e-mail]
Subject: re: other ways for viral injection?

>        Does somebody known if there was some cases of
>viral infection that came through other than floppy exchange
>and data interchange over Internet ? I think to other networks,
>through atmospheric radio transmissions, magnetic induction, ...

          I think back to a wonderful little nasty from the CP/M
days. There was a version of MODEM7 floating around that had a patch
in it that caused it to do all sorts of neat things when certain
character sequences were received over the async channel. One of these
nasty things was to take a character string coming in over the modem
and patch it into the bios at a jump vector specified in the incoming
string. I'm sure this was probably intended to allow someone to do
something useful such as replace I/O drivers on the fly for things
like remote tty services or other form of redirection. But, if you had
a nasty streak and you knew about this 'backdoor', imagine the damage
you could have done. (btw: it did this patching with no notification
to the user of the 'patched' machine). This was actually one of the
slickest little routines I ever saw in the CP/M 'virus/trojan' category
and it has caused me to run all of my comm programs through a datagram
analyzer while I'm 'breaking them in'. Especially if they are 'special'
purpose comm programs or if they require passwords to be automatically
sent by the package rather than manually entered by the user. As for
other networks....I can't think of a network that HASN'T come under attack
in one way or another. Magnetic induction? Hmmmm...I don't think the
technology is advanced enough to permit a focused field of the precision
required to affect a machine (selectively altering bits that is) from
an external source. Of course a good magnetic 'bulk eraser' provides a
quick method of simplifying your file management :)

____________________________________________________________________________
        ===
      =--====  AT&T Canada Inc.             John Benfield
     =----==== 3650 Victoria Park Ave.      Network Support Analyst (MIS)
     =----==== Suite 800
     ==--===== Willowdale, Ontario          attmail   : ~jbenfield
      =======  M2H-3P7                                email     : uunet!attcan!john
        ===    [phone]               Compu$erve: 72137,722

____"Sometimes it just happens...People explode...Natural causes."__________

------------------------------

Date:    Mon, 30 Jul 90 17:29:14 -0400
From:    [e-mail] (Alan J Rosenthal)
Subject: mac disk locking (Mac)


[e-mail] writes:
[disk is damaged]
>The catcher is this: although the disk is physically unlocked, it is marked
>"locked" under the info box, and cannot be modified or unlocked.

You may not be aware that mac floppies have software and hardware
locking.  I don't know how to set or unset the software lock on
floppies, but Virus Blockade has an option to do this.

ajr

------------------------------

Date:    Mon, 30 Jul 90 19:10:36 -0400
From:    <[e-mail]>
Subject: Stoned Remover (PC)

The stoned is a troublesome virus because it infects the hard disk
partition table. If left on the hard disk, it will eventually corrupt
the FAT (this is due to compatability problems and was not intended by
the author of the virus). Here is a short assembler program to remove
it from the hard disk. It can be assem- bled through DEBUG

DEBUG
- -A
MOV DX,80    ; THE HARD DISK, HEAD 0
MOV DX,7     ; CLUSTER 0, SECTOR 7
MOV BX,200   ; MEMORY LOCATION 200
MOV AX,201   ; READ FROM HARD DISK TO MEMORY
INT 13       ; DISK ACCESS
MOV CX,1     ; CLUSTER 0, SECTOR 1 (THE PARTITION TABLE)
MOV AX,301   ; WRITE FROM MEMORY TO HARD DISK
INT 13       ; DISK ACCESS
MOV AH,0     ; RESET AH REGISTER
INT 21       ; TERMINATE

N STONEDHD.COM
RCX
:30
W
Q

Only use this on hard drives that are infected. It will destroy the
partition table on uninfected drives.

This program will remove it from drive A:

DEBUG
A
MOV DX,100  ; HEAD 1, DRIVE A:
MOV CX,3    ; CLUSTER 0 SECTOR 3
MOV BX,200  ; MEMORY LOCATION 200
MOV AX,201  ; READ FROM DISK TO MEMORY
INT 13      ; DISK ACCESS
MOV DX,0    ; HEAD 0 DRIVE A:
MOV CX,1    ; CLUSTER 0, SECTOR 1 ( THE BOOT RECORD)
MOV AX,301  ; WRITE FROM MEMORY TO DISK
MOV AH,0    ; RESET AH REGISTER
INT 21      ; END

N STONEDA.COM
RCX
:30
W
Q

This will remove it from drive A:
To do a lot of disks, try this
Put an uninfected disk in A:
DEBUG
L 0 0 0 1
Put an infected disk in A:
W 0 0 0 1
Put another infected disk in A:
W
Repeat as often as necessary

If you have any mor questions or need any more help, drop me a
line.............

Mike McCune...<MM>

------------------------------

Date:    Tue, 31 Jul 90 11:49:03 -0400
From:    Kenneth R. van Wyk <[e-mail]>
Subject: Back issues now available in indexed/digested format

                          A long time ago,
                    from a computer far far away,
                 VIRUS-L was unmoderated and undigested.

Sorry...  Bad attempt at humor.  Anyway, as I was saying, V-L existed
in a very different form from the day that it was started (April 22,
1988) until shortly after the Internet worm of November 1988.
Previously, all of the pre-digest traffic has been available on both
Lehigh's LISTSERV machine (LEHIIBM1 from BITNET or IBM1.CC.LEHIGH.EDU
from Internet) and the CERT ftp machine (cert.sei.cmu.edu) in the form
of weekly logs.  Anthony Appleyard,
[e-mail], has graciously (and
painstakingly) compiled these weekly logs into digests.  The digests
make up volume 0 and are now available for anonymous FTP on
cert.sei.cmu.edu in the pub/virus-l/archives/predig.digested
directory.  The information in volume 0 is somewhat dated, of course,
but can provide some interesting insight into current virus events
(and perhaps a laugh or two - things have changed a bit...).

Also included in all of this is an index to volume 0.  That, too, is
on the CERT anonymous FTP machine, in the pub/virus-l/archives
directory.

A wholehearted thanks to Anthony for his effort on putting together
all of this traffic!

Cheers,

Ken van Wyk

------------------------------

Date:    Tue, 31 Jul 90 14:49:00 -0400
From:    Don Kazem <[e-mail]>
Subject: Site licenses

We have been thinking about standardizing on a virus
scanner/disinfector for our organization. We have about 1500 users.

Our vision is to have a scanner/disinfector package available
to the PC support analysts and have them use it on suspicious
machines or perform random audits.

I have been thinking about purchasing a Service Industry
License from McAfee Associates. The total package would cost
about $6800.00 for (20 copies). This license would allow us
to perform checks on various machines, however, the software
must not remain with the clients.

Has anyone one else in the corporate arena implemented such a
policy/structure?

Don Kazem
National Academy of Sciences
[e-mail]

------------------------------

Date:    Tue, 31 Jul 90 17:41:58 -0700
From:    [e-mail]
Subject: Joshi-B Infection Alert (PC)

This is a forward from Aryeh Goretsky of the Computer Virus
Industry Association:
================================================================

Note:  Contact information from the following CVIA Membership Alert
has been removed from the posting, but has been submitted
separately to the Virus-L moderator.

July 31, 1990
CVIA Membership Alert
Originating Member: [Information Removed]
Alert Type: Initial Infection Spread
Library Entry: Joshi-B
Entry Type: Boot Sector & Partition Table / "Stealth" Virus

          The Joshi virus has been reported and verified on July 30 on
a number of workstations in a local area network in North Carolina,
marking the first incident of the virus reported to the CVIA in the
South-Central U.S.  A variant of Joshi was also reported and
verified on July 31 in Riyadh, Saudi Arabia.  It has been named the
Joshi-B.  This variant causes destruction of the Partition Record
and boot sector of hard disks, as well as the virus' normal
interference with floppy diskette use.
          The virus is a "stealth" Boot sector and Partition Table virus
and thus is very difficult to identify on an already infected
system.  It is becoming widely dispersed in the U.S. and is likely
to become one of the more common viruses, based on its past
performance and speed of replication.
          A remover for the virus is available through your CVIA contact
person.

John McAfee

------------------------------

Date:    Wed, 01 Aug 90 09:19:13 -0400
From:    "Kenneth R. van Wyk" <[e-mail]>
Subject: Periodic virus sighting report

The following new virus infections were reported recently:

- - First sighting of Slow (PC) virus reported in Australia.  Major
  infection path so far seems to be Taiwan -> Hong Kong -> Phillipines
  -> Malaysia -> New Zealand -> Australia.

- - Joshi (PC) virus reported in Lakeland Florida area.

- - 4096 (PC) virus reported in Spokane/Seattle Washington area.
  Several sites hit.

These sightings were reported to me; they are in addition to the other
reports that have appeared on VALERT-L and/or VIRUS-L.  When possible,
I have phoned at least one contact in the area to verify the
sightings.

Ken van Wyk
August 1, 1990

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 136]
******************************************
VIRUS-L Digest   Thursday,  2 Aug 1990    Volume 3 : Issue 137

Today's Topics:

Does 4096 attack boot sectors ? (Was: We have been hit !!!) (PC)
"Slow" virus (PC)
4096 Running Rampant At Wharton! (PC)
Antivirus-viruses
Military Viruses - Update
PC Virus Frequency List FYI (PC)
Possible Problems with VSHIELD and NK.EXE?? (PC)
Virusafe
Re: LaserWriter virus?

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 01 Aug 90 16:33:03 +0700
From:    David de Leeuw <[e-mail]>
Subject: Does 4096 attack boot sectors ? (Was: We have been hit !!!) (PC)

I wrote that 4096 does attack the boot sector.

David M. Chess and Y. Radai doubt this.

I should state that my observation was based on circumstantial
evidence only: four computers here refused to boot after massive
attacks by 4096. Also Michael Greve's original letter states that his
computers would not boot anymore. After antiviral cleaning and SYS the
systems boot again. I will try to isolate the virus to have it
compared by Y. Radai with the "original" 4096.

Are mutations also known in computer viruses ?

David de Leeuw
Ben Gurion Univ of the Negev

------------------------------

Date:    01 Aug 90 10:02:04 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: "Slow" virus (PC)

> First sighting of Slow (PC) virus reported in Australia.

Coincidentally, we just got a report from Australia as well.
Does anyone know offhand why the virus is called "slow"?
I don't see any code that slows the machine down all that
much.   I probably just missed it...

Some findings about "Slow"; based on code analysis, not
on any testing:
  - Self-garbling, like the 17xx family et all, but with a
    reasonably large invariant part.  Data areas are stored
    under a second level of XOR-garble, for some reason.
  - Much of the code is taken from the 1813 (Jerusalem) virus,
    but Slow is better at telling EXE-format from COM-format
    files, and doesn't have the EXE-reinfecting bug.
  - Like the 1813, it goes resident when the first infected
    program is run, and infects anything executed thereafter.
  - Only "damage" seems to be that, on some Fridays after 1990,
    something like every other file-close will cause the file's
    timestamp to be set to zero.   Sort of odd!
  - The virus has a five-byte self-id string that infected files
    will end with.   It will rarely -change- this self-id; it
    stores both the current one, and one previous one, to avoid
    too much re-infection.   This is no doubt to avoid
    "innoculators" (which were never very interesting to start with).
  - Like the 1813, it sets the CRC in the header of infected EXE
    files to 1984; but it never uses the fact.   Either the author
    wanted to make Slow-infected files immune to the 1813, or
    (more likely) he just didn't understand the 1813's code
    well enough to know that the setting-to-1984 wasn't needed.

Any information about the "Slow" that adds to, or contradicts,
the above would be appreciated!

DC

------------------------------

Date:    Wed, 01 Aug 90 10:11:00 -0400
From:    Michael Greve <[e-mail]>
Subject: 4096 Running Rampant At Wharton! (PC)

    We thought we had rid ourselves of the 4096 virus.  Since I last wrote
   to this list the 4096 virus has re-infected the orginal 5 machines in
   our lab plus 4 more.  We seem to be losing the battle of 4096.  What
   I feel is wrong is that we probably have some students with infected
   com and exe files on their floppies (programs, games etc.).  They are
   using their programs and re-infecting our machines (unknowingly).  We
   are currently using Diskmanager as our hard disk protection software.
   Diskmanager isn't protecting the machine against 4096.  Is there a
   program, either shareware or by purchase, that will work with Diskmanager
   and protect the machine from 4096?  At this point we don't have the
   virus under control.  We don't have the capabilities to check students
   disks.  We are closing the lab and re-formatting all the machines. Another
   lab will be closed tomorrow for a entire lab check.  If this virus is on
   student diskettes then any machine could be infected and it could spread
   throughout Penn.  I don't mean to sound so negative, but I am concerned.

                                        Thanks again for any assistance.

                                                  Michael Greve
                                                  greve@wharton,upenn.edu
                                                  The Wharton School
                                                  University of Pa.

------------------------------

Date:    Wed, 01 Aug 90 15:41:48 +0100
From:    Anthony Appleyard <[e-mail]>
Subject: Antivirus-viruses

There has been several bouts of discussion on Virus-L  on  the  subject  of
antivirals that spread like viruses. As far as I can tell from reading back
issues of Virus-L, a few antivirus viruses have been released, with varying
results:-

(1) Mac: The original nVIR deleted  a  system  file,  so  a  new  nVIR  was
released which killed the old one.

(2) PC: Den Zuk was  released  to  kill  Brain;  it  also  killed  obsolete
versions  of  itself. But Den Zuk had a bug, which made it delete data when
infecting small disks.

(3) Amiga: North Star (I & II), supposed to kill other viruses and  nothing
else.  It works like a normal bootblock virus, with two good exceptions. If
it finds a unknown bootblock (normally an auto-loading  game),  it  DOESN'T
replace that bootblock, so the game keeps working. If it finds a virus on a
write-protected disk, it asks you to remove the write-protection.

(4) Amiga: System Z (3.0 & 4.0 & 5.0): boot sector virus, asks  the  user's
permission before infecting anything.

The arguments put against them are:-

(1) Ethics: System Z handles this point by  asking  the  user's  permission
before infecting.

(2) Risk of them malfunctioning and becoming ordinary harmful viruses: E.g.
Den Zuk. This point should be handled by thorough  testing  and  debugging.

(3) Risk of them being  hacked  into  harmful  viruses:  There  are  enough
ordinary  harmful  viruses  about  for  virus-writers to hack at. Antivirus
viruses can be protected by  some  sort  of  internal  checksum  tested  by
well-encrypted code, to test for unauthorized alteration.

The  main  inaccessible  reservoir  of  virus   infection   is   the   many
microcomputers  in  private  ownership,  often  used mainly by children and
teenagers, who are often ignorant of viruses, imagining that  virus  damage
is  hardware  malfunction  or software bug or the way of the world, with no
hope of access to email or the usual channels of  getting  virus  news  and
antivirals. There are far too many of these micros for any sort of national
register  to  be  kept of where each is kept, for a tester to go round them
like in a firm or a university. The only way that I can see of getting some
sort of antiviral well distributed among this widely scattered  chronically
infested  population, would be for the antiviral to distribute itself, i.e.
to spread like a virus. It is a choice of evils. For example,  if  Den  Zuk
hadn't  got  the bug of malfunctioning on small disks, it would likely have
spread largely ignored, and flushed out the harmful Brain from most of  the
places  where  it breeds in children's bedrooms among unsupervised IBM PC's
and casually-exchanged game floppies, until a Brain-infected videogame gets
run on a university or official or school computer and endangers  important
programs and data.

{A.Appleyard} (email: [e-mail]), Wed, 01 Aug 90  14:50:32  BST

------------------------------

Date:    Wed, 01 Aug 90 10:31:53 -0400
From:    Nick DiGiovanni <[e-mail]>
Subject: Military Viruses - Update

Business Week, July 23, p.30 ('Killer' Computer Viruses: An Idea Whose
Time Shouldn't Come, Mark Lewyn) reports the DOD's Center for Signals
Warfare (CSW) has received 19 proposals from software companies and
developers to create computer viruses that infiltrate and destroy
enemy communications systems.  Seems things are moving along nicely
towards development of a software version of the Andromeda Strain.

Nick Di Giovanni
EDP Audit Manager
Rutgers University

------------------------------

Date:    1 August, 1990
From:    Padgett Peterson <[e-mail]>
Subject: PC Virus Frequency List FYI (PC)

Virus Frequency List - extracted from Patricia Hoffman's VSUM9007,
July 1990 These are the viruses flagged as COMMON & NEW only. Those
flagged as Extinct, Endangered, Rare, or Mythical have been omitted.
For those interested in the complete listing, it is available from
HOMEBASE [phone] or EXCALIBUR! [phone] & I believe it is
now on SIMTEL20. From what I am seeing, the 4096 and JOSHI are going
to be much more difficult to detect and deal with than the other
rather crude strains we are used to.

  4096                  Common
  Ashar                 Common
  Brain                 Common
  Cascade               Common
  Cascade-B             Common
  Dark Avenger          Common
  Den Zuk               Common
  Disk Killer           Common
  Jerusalem             Common
  Jerusalem B           Common
  Joshi                 Common
  Korea                 Common - Korea
  Microbes              Common - India
  Murphy                Common - Bulgaria
  Ohio                  Common
  Ping Pong-B           Common
  Stoned                Common
  Sunday                Common
  Yankee Doodle         Common - Europe

  1008                  New
  1381 Virus            New
  Flash                 New

[Ed. The VSUM document is also available on cert.sei.cmu.edu, in the
pub/virus-l/docs directory, for anonymous FTP.]

------------------------------

Date:    27 Jul 90 21:04:00 -0500
From:    "6SWSCX" <[e-mail]>
Subject: Possible Problems with VSHIELD and NK.EXE?? (PC)

I have a Zenithe Z-184 Laptop system with the NUMERIKEYS external
keypad installed. SCANRES ver 61 did not have any problems with
the NK.EXE file that is the software driver for the keypad. When
I loaded VSHIELD ver 64, it indicates that NK.EXE is infected with t
with the [1381] Virus. I double checked the master disks, which
had previously ben used only to make backup copies, and the
NK.EXE is shown to be infected on them. I have had no probelms with
the computer or any of the files today,so I'm wondering if
this is really an infected file or just a misidentification by
VSHIELD?

Has anyone else seen this type of problem?

Regards,
          Tom Creek

------------------------------

Date:    Wed, 01 Aug 90 16:04:20 -0500
From:    martha rapp <[e-mail]>
Subject: Virusafe

Has anyone ever head of Virusafe?  I have never seen any reference to it in
Virus-l.  Thanks.
                                    Martha Rapp
                                    Computing Services
                                    IUPUI

------------------------------

Date:    02 Aug 90 03:54:42 +0000
From:    [e-mail] (Woody Baker @ Eagle Signal)
Subject: Re: LaserWriter virus?

I'd like to thank Ken for posting the code, and to aplogize to him for
the rather abrasive note that I sent him.  I have since recieved a
series of questions from an individual about the contents of the code.
I have examined the hex code.  It is encrypted via a standard
encryption routine used by Adobe, and documented in the new Black Book
(the Type 1 Font Spec) book.  The core routine, the 68000 machine
language rotine is identical to the routine that I use for reading the
eeprom, right down to the checksum.  Since machine language routines
have to be installed by the cexec operator, and since that operator
will not function unless it is invoked from within a procedure that
has been called via eexec (known as executing from within an eexec
context), Nigel simply did the following:

<
......680000 code
> userdict begin cexec currentfile closefile

and eexeced it.  Then when eexec executes, the machine language will
be executed by cexec, and the operator installed.  I have taken
a slightly diffrent tack, to achieve the same result.  The dangerous
routine,  writeeeprom is a separate bit of 68000 code.  I have decided
to remove that from my code, so at this point my code is essentialy
the same as Nigels code, except that I don't chage the password.  I just
report it.

As was pointed out, this is a double edged sword.  If you know the
password you can reset the password.  This routine shows you the
password.  If you choose, you can then reset it to some other value.
This means that this routine could be used as the primary attack to
change the password, and mess things up.  It also means that if that
happens, you can know about it and fix it.  The universe is perverse.
It is, however, better to be able to undo the damage when it is done
than not to be able to undo the damage.

Cheers
Woody

p.s.  The code posted is a simple text file that can be sent to any
Adobe 68000 postscript printer by any means whatsoever from any host
whatsoever.  It cannot hurt the host in anyway.

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 137]
******************************************
VIRUS-L Digest   Friday,  3 Aug 1990    Volume 3 : Issue 138

Today's Topics:

Various subjects (PC)
re: Antivirus-viruses
Virus documentation
New link virus: COM + 453, direct action (PC)
Forwarded: POSSIBLE PROGRAM TROJAN HORSE!! (PC)
4096 Virus and Checksums (PC)
4096 Running Rampant at Wharton! (PC)
Virus information requested
Re: Site licenses
Re: 4096 Running Rampant At Wharton! (PC)
Re: Site licenses
F-PROT experience, anyone?
4096 in Bradford, UK (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Thu, 02 Aug 90 13:23:11 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Various subjects (PC)

F-PROT news

F-PROT version 1.12 is finished - It is not completely up to date, as I have
not yet been able to obtain samples of some very recent viruses (Sublimal and
Poem for example).  The next update will therefore appear soon - expect 1.13
late in August.

The program has been sent to everybody on my distribution list, and has also
been uploaded to chyde.uwasa.fi.  I also expect it to appear soon on
comp.binaries.ibm.pc.

"Stealth" virus

I have seen the name "Stealth" used for 4 different viruses, 4096 (Frodo, IDF)
and 1260, as well as two of the Bulgarian viruses.  This is too confusing, so
what I propose (and what I will do in version 1.13 of F-PROT) is to use
"Stealth" to refer to a class of viruses - the viruses that attempt to hide
from detection, using a variety of methods. Comments, anybody ?

Lost mail

Some time ago I deleted several mail messages by accident. I assume many of
them were virus-related, so if any of you sent me mail about three weeks ago
and have not received a reply, I probably lost your messages.  Sorry :-(
Just E-mail me again, but don't expect a reply until in about 10 days or so,
because .....

Vacation time

I am going on a vacation today - the first time for more than two years when
I will not have a computer in front of me most of the day.  I will be back on
August 10.........

- -frisk
- --
Fridrik Skulason      University of Iceland  |
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: [e-mail]    Fax: [phone]  |

------------------------------

Date:    02 Aug 90 09:33:09 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: re: Antivirus-viruses

Anthony Appleyard <[e-mail]>
writes, among other things:

> For example, if Den Zuk hadn't got the bug of malfunctioning on
> small disks, it would likely have spread largely ignored, and
> flushed out the harmful Brain from most of the places where it
> breeds...

I imagine there will be lots of flames on this, and I don't
really want to add to them (on the other hand, I don't
want there to be no response to the item, so here I am!).

I'm not sure if Mr. Appleyard means to imply that if the Den Zuk had
only been less buggy, it would have been a Good Thing; if that's the
intent, though, I'd like to disagree strongly!  Any virus (with or
without the Den Zuk's Brain-removal, "logo" and other side effects)
that messes around with my system without my knowledge is a Bad Thing.
It will eventually spread to some place where it will do harm (a
non-standard disk format that it doesn't notice, but messes up; a new
version of the op system that it's not compatible with; or whatever).

The only anti-virus virus that would be at all defensible would be
one that announced itself in large and unmissable letters when first
run, and gave the user the option (which I, personally, would always
exercise) to tell it to erase itself completely from the system.
Even then, I don't entirely share Mr. Appleyard's confidence that
there are already so many sample viruses out there that one more
won't provide budding virus writers with extra education.  I'm not
certain that it would, but I wouldn't want to take the chance...

DC

------------------------------

Date:    Thu, 02 Aug 90 10:47:00 -0400
From:    "Michael N. Davis" <[e-mail]>
Subject: Virus documentation

I just joined this list and I was wondering if this list maintains an
archive of full documentation on each virus.  For example, a warning
has gone out about the 4096 virus at a med school in a nearby city
that I do some pc work for.  The report said that there was no
software that could detect and remove it.  Someone here at my
institution told me that there is software to detect and remove it.
It would be nice if I could get at will an archive file from this list
fully describing the 4096 virus, its modus operandi, and the software
that will cure it.  Does such exists and if so how do I access it from
BITNET?

Thanks.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Michael N. Davis, System Manager, NC A&T State University, Greensboro, NC 27411
BITNET: DAVISM@ATSUVAX1

------------------------------

Date:    02 Aug 90 16:10:23 -0500
From:    "Otto Stolz" <[e-mail]>
Subject: New link virus: COM + 453, direct action (PC)

In the HQ of Sxdwestdeutscher Bibliotheks-Verbund (located at the
university of Constance, Germany), a new virus has been detected.  The
virus adds 453 (four hundred fifty three) bytes to COM files.  (It is
neither the V-345 from the Amstrad strain, nor the Vienna 435.)
F-FCHK and SCAN do not recognize this virus.

It is not yet know whether this virus carries a payload.

I know that it infects COM files in the local directory; whilst it did
not infect files in other directories during my tests, we cannot be
completely sure about the infection mechanism until the virus has been
dis-assembled.

Following are my preliminary findings in VTC format.
I'll send a sample to the VTC at Hamburg for further investigation.

If anybody has already seen this beast and knows more than I do (cf.
infra), please drop me a note.

Otto

- ---------------
Entry................. ((not yet assigned -- anything alluding to the
                       length would be confusing, as we have already
                       435 and 345 viruses))
Alias(es).............
Strain................
Detected: when........ 1 Aug 1990
          where....... Sxdwestdeutscher Bibliotheksverbund
                       (located at Universit2t Konstanz)
Classification........ Link virus, direct action COM infector
Length of virus....... 453 bytes added to COM files
- ----------------------- Preconditions --------------------------------
Operating System(s)...
Version/Release.......
Computer models.......
- ------------------------Attributes -----------------------------------
Easy identification... File size increases by 453 bytes
                       The following offsets are taken relative to the
                       address the JMP instruction (cf. infra) points to.

                       offset | string / bytes found
                       -------+----------------------------------
                         007  | "VIRUS"
                         00D  | "*.COM"
                         013  | "????????COM"
                         030  | file-id of the infected program
                         043  | original contents of 1st 3 bytes
                         052  | "TUQ.RPVS"

Type of infection..... Direct action.
                       Begin of program is overwritten with JMP
                       instruction pointing to appended viral code.

Infection trigger..... Executing an infected file will trigger the
                       infection attempt in the local directory.
                       Virus has been tested with one bait (at most)
                       available, so it is not clear whether multiple
                       programs will be infected. No files outside the
                       local directory have been infected during tests.

Interrupts hooked..... none
Damage................
Particularities.......
- ----------------------- Acknowledgement ------------------------------
Location.............. Rechenzentrum der Universit2t Konstanz
Classification by..... Otto Stolz <RZOTTO at DKNKURZ1.BITNET>
Dokumentation by ..... Otto Stolz <RZOTTO at DKNKURZ1.BITNET>
Date.................. 1990-08-02

------------------------------

Date:    Thu, 02 Aug 90 12:02:35 -0700
From:    [e-mail] (Rollo D. Rogers)
Subject: Forwarded: POSSIBLE PROGRAM TROJAN HORSE!! (PC)

The info below was provided by our local Computer REsource Center. I
contacted the sender below and tried to get more details on this.
However, he told me he had gotten the info from a third party. So
there is no local confirmation that this is a real trojan horse
running around within this program. Since the trigger date was two
days ago, thought you might wish to distribute this information, so
users who currently have or contemplate obtaining this software can be
forewarned. Sorry i could not obtain more complete details.  I was
told this could be the commercial or PD version of the software.

- -------
>From marlin!nosc!manta!bray Wed Aug  1 15:41:42 PDT 1990
Article 660 of nosc.micro:
Path: marlin!nosc!manta!bray
>From: [e-mail] (Robert E. Bray)
Newsgroups: nosc.micro
Subject: DISCOVER Program Warning
Keywords: disk management utility, program problems
Message-ID: <[e-mail]>
Date: 1 Aug 90 22:01:12 GMT
Distribution: nosc
Organization: Naval Ocean Systems Center, San Diego
Lines: 16

- -------
DISCOVER Program Users:

It has come to the attention of the CRC that the PC program called,
DISCOVER (a disk management desktop utility similar to PC Tools, Norton
Commander, XTREE Pro, etc.), has been programmed with a trigger to
begin ciphering files/directories that are referenced or created AFTER
31 JULY 1990, AND it doesn't let you un-cipher those files/directories!

Users beware--you may want to stop using DISCOVER asap.

Currently, further information on this problem is limited.  However, if
you have questions, call the CRC (Bayside x32247 or Topside x32268).

Bob B. (Bayside CRC)
- -------

------------------------------

Date:    02 Aug 90 13:39:32 -0400
From:    Steve Albrecht <[e-mail]>
Subject: 4096 Virus and Checksums (PC)

In browsing through the April 1990 issue of Computers and Security,
Volume 9, No. 2, I read the following comments of Dr. Harold
Highland on the 4096 virus:

     "This recently published computer virus is particularly
     disturbing in that...checksum techniques likewise appear to
     be useless, the virus `disappears' during the checksum
     process..."

Can someone please elaborate on how the virus avoids the checksum
process, or perhaps direct me to more detailed information on this
virus?

In particular, does it avoid all checksum algorithms, or only
certain ones?  How does it avoid detection from the checksum
operation?

Any help would be most appreciated.


Steve Albrecht
MIS Field Services
PLAN International
70033,[e-mail]

------------------------------

Date:    Thu, 02 Aug 90 15:07:25 -0500
From:    martha rapp <[e-mail]>
Subject: 4096 Running Rampant at Wharton! (PC)

Michael,

      You must find a way to check and remove the virus from
Students's or the lab will never completely get rid of the infection.
Get an old machine wit h the proper size drives and set it up near the
doorway and don't allow anyone to use the machines if their disks have
not be certified virus free.  I don't t hink that Diskmanager is a
anti-virus program.  Use and pay for Scan from McAfe e or something
similar and ensure that you can get updates easily.  The main it em is
that with hard drives on your machines you must constantly check for
viru sues.
                                    Martha Rapp
                                    Computing Services
                                    IUPUI

------------------------------

Date:    02 Aug 90 15:17:33 +0000
From:    cdss![e-mail] (Risa Hyman x2021)
Subject: Virus information requested

Hello Netlanders,

I am posting this for a student at the University of Maryland and also
for our own development information.  Would appreciate info on virus
screens, virus scanning packages and successful approaches that you
have found in dealing with these threats to our open network of
communication.  His class does not have access during the summer
session to the Internet, and we have been so busy on our development
set up that we have neglected to become smart enough, fast enough.
We've read the books, but real life information is better.  Any info
on public domain virus screens would be great.

Thanks in advance as always.

- --
Risa B Hyman                                      Any opinions expressed are my own.
Arinc Research Inc                      uucp : uunet!cdss!hyman
SRG, Mail Stop 5230                     voice: 301 266 2021
2551 Riva Road Annapolis , MD 21401     fax  : [phone]

------------------------------

Date:    Thu, 02 Aug 90 21:26:12 +0000
From:    plains!umn-cs!LOCAL![e-mail] (Brian Aslakson)
Subject: Re: Site licenses

[e-mail] (Don Kazem) writes:

>We have been thinking about standardizing on a virus
>scanner/disinfector for our organization. We have about 1500 users.

>Our vision is to have a scanner/disinfector package available
>to the PC support analysts and have them use it on suspicious
>machines or perform random audits.

>I have been thinking about purchasing a Service Industry
>License from McAfee Associates. The total package would cost
>about $6800.00 for (20 copies). This license would allow us
>to perform checks on various machines, however, the software
>must not remain with the clients.

The security guy here got a good laugh and said that you must be a
couple decimal places off.  68$.  I could believe 680$ (maybe).

I don't know FPROT (fprot111.zip via mibsrv.mib.eng.ua.edu in
pub/ibm-antivirus via anonymous ftp) but the security guy recommends
it and they charge either one or two dollars per machine in large
numbers...

Brian Aslakson
- --
Macintosh related:  [e-mail]
All else:  [e-mail]

------------------------------

Date:    Thu, 02 Aug 90 21:59:37 +0000
From:    plains!umn-cs!LOCAL![e-mail] (Brian Aslakson)
Subject: Re: 4096 Running Rampant At Wharton! (PC)

[e-mail] (Michael Greve) writes:

>    We thought we had rid ourselves of the 4096 virus.  Since I last wrote
>   to this list the 4096 virus has re-infected the orginal 5 machines in
>   our lab plus 4 more.  We seem to be losing the battle of 4096.  What
>   I feel is wrong is that we probably have some students with infected
>   com and exe files on their floppies (programs, games etc.).  They are
>   using their programs and re-infecting our machines (unknowingly).  We
>   are currently using Diskmanager as our hard disk protection software.
>   Diskmanager isn't protecting the machine against 4096.  Is there a
>   program, either shareware or by purchase, that will work with Diskmanager
>   and protect the machine from 4096?  At this point we don't have the

DiskManager, by Ontrack Software [phone], is not anti-viral
software, has never claimed to be (I'll betcha) anti-viral, and if you
told them -- wait --, I'll tell them.
         I didn't have to finish asking my question about anti-viral
when the man said "No."  It isn't anti-viral, never claimed to be
anti-viral, it partions Harddisks.  That's what it does.  Okay?  "No.
No.  No."

Anyway, get either scan or fprot (or both), also get some memory
resident program like scanres or vshield.  Fprot may have something
like this in it (with it).  READ the documentation.  Try anonymous ftp
at mibsrv.mib.eng.ua.edu goto pub/ibm-antivirus and mget til you're
blue in the face.  There is some excellent stuff there.  scanv64.zip
fprot111.zip vshld64.zip and so on....

Try to download to a clean machine, read everything, then go for it.
Scanres you'll have to get from McAfee's BBS directly, if you want it.
The number's in the documentation for scan.  Fprot I'm checking out
tonite.

Good luck.

Brian Aslakson
- --
Macintosh related:  [e-mail]
All else:  [e-mail]

------------------------------

Date:    Thu, 02 Aug 90 20:59:21 +0000
From:    [e-mail] (Frotz)
Subject: Re: Site licenses

[e-mail] (Don Kazem) writes:
] We have been thinking about standardizing on a virus
] scanner/disinfector for our organization. We have about 1500 users.

          We have about 200.

] Our vision is to have a scanner/disinfector package available
] to the PC support analysts and have them use it on suspicious
] machines or perform random audits.

We intend to put dedicated PC class machines (no or very *tiny* hard
disk ~10M) in stations around the company.  We can do this because we
have so many of these low class machines practically lying around.
These machines would contain one of these licensed disinfectants and
would provide local access to the latest disinfectant and would allow
users to easily check software that has come in from questionable
sources (e.g. BBS' or via Tech Support...)

] I have been thinking about purchasing a Service Industry
] License from McAfee Associates.

It has been suggested that we do this as well.  I am still evaluating
other resources (e.g. This newsgroup.) before I commit to doing this,
though I agree that it is very cost effective (psychologically to
upper management) to have direct associations with McAfee Associates.

] Has anyone one else in the corporate arena implemented such a
] policy/structure?

We are in the very early stages of defining and implementing this.
Will post more as I get a better handle on things.
- --
John "Frotz" Fa'atuai         [e-mail]     (email@domain)
Digital Research, Inc.        {uunet|amdahl}!drivax!frotz   (bang!email)
c/o MIS Dept.                 [phone]                          (vmail)
80 Garden Court, C13          [phone]                          (phone)
Monterey, CA  93940 [phone]                          (fax)

------------------------------

Date:    03 Aug 90 03:38:14 +0000
From:    [e-mail] (Sigurd Andersen)
Subject: F-PROT experience, anyone?

Academic Computing Support at the University of Delaware is
considering licensing F-PROT, a set of programs by Fridrik Skulason
([e-mail]).

I'd like to know if anyone has reviewed or tested these programs,
and what their experience has been.

I can summarize responses if people are interested.

------------------------------

Date:    Thu, 02 Aug 90 10:07:50 +0000
From:    Drew <[e-mail]>
Subject: 4096 in Bradford, UK (PC)

Just  for  the record, here's a few details of a recent attack of the 4096
virus at the University of Bradford in the UK.

In  May  1990  I  found  a  copy on one of our machines in our department.
Having identified it as 4096 and removed it with the latest version of the
excellent Scan from McAfee.  Talking to one of our students she  indicated
it had come from our computer centre

It  seemed  the CC here has a version of Netscan installed on their Novell
Networks which was not current enough to be able to detect it, hence  they
seemed to be lulled into a false sense of security.

Anyway  it  was all removed eventually, but it was the most virulant viral
attack at the University.   Previously  we've  had  Brain  and  Vienna  on
Computer Centre PCs, and nVIR B and WDEF B on their Macs.

Obviously  if  we  have  had  it here it must be common within the UK, and
perhaps more widespread in Europe and the US than people may imagine.

Drew Radtke
- -----------
Janet:       [e-mail]2
Internet:    [e-mail]
Earn/Bitnet: Drew%cyber2.central.bradford.ac.uk@ukacrl
UUCP:        [e-mail]
Post:        Science & Society, University of Bradford, Bradford, UK, BD7 1DP.
Phone:       [phone] x6135
Fax:         [phone]
Telex:       51309 UNIBFD G

PS Could Friderick Skulason send me his notes on this virus as I am
interested in his opinions and ideas?

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 138]
******************************************
VIRUS-L Digest   Wednesday,  8 Aug 1990    Volume 3 : Issue 139

Today's Topics:

SAM Loophole (Mac)
4096 (PC)
453 Virus (PC)
Re: other ways for viral injection ?
Gatekeeper Aid 1.0.2 (Mac)
Joshi Remover (PC)
CVIA Alert (PC)
Viruscan Site Licensing

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 03 Aug 90 12:27:30 -0400
From:    <[e-mail]>
Subject: SAM Loophole (Mac)

  Another Loophole in SAM Intercept

  Folks:

We have discovered another loophole that can allow a person to bypass the
floppy scan in SAM intercept.

If you are in an application and want to open a file on a floppy, SAM
will scan the floppy you insert. If, however, while in the File Open
dialog box, you click on EJECT and insert another floppy, this floppy
(and any other subsequent floppies you insert) are not scanned by SAM.

This "loophole" in SAM would allow you to infect your unit if there is
a virus on the second or later floppies. Since most viruses go on to
infect the system files, SAM would pick up the infection the next time
you reboot your machine (provided you have configured your copy to
scan the system folder at startup)

We have notified Symantec of this loophole and would appreciate further
confirmation.

------------------------------

Date:    3 Aug. 1990
From:    Padgett Peterson <[e-mail]>
Subject: 4096 (PC)

          I have been surprised to the the excitement caused by this virus.
Admittedly, it uses some "stealth" techniques to hide itself, but the
"stealth" itself should be detectable in memory. Certainly a thorough virus
checking routine will not rely on DOS to provide accurate information. Next,
despite roumors of CMOS and Modem viruses, to be able to become resident in
an XT class machine, some memory MUST be used somewhere and this is detectable.

          Thus there are (at the moment) three checkpoints: either available
memory has been reduced, interrupts are being vectored into never-never land
(virus hiding in unassigned memory - note: this may not be obvious from the
interrupt table), or crashes will occur often as the virus is overwritten.
While I have not yet seen the 4096 (a copy is coming but not yet arrived),
I feel certain that it is detectable reasonably easily in memory - if not
directly then by its process of hiding. As soon as I determine an easy way to
detect it, the answer will be posted. In the meantime, booting from a write-
protected floppy and running a clean SCAN of version 53 or later is known
to be effective.


------------------------------

Date:    3 August, 1990
From:    Padgett Peterson <[e-mail]>
Subject: 453 Virus (PC)

          Otto Stolz was kind enough to forward to me a hex dump of
the 453 virus and the following information is now available:

1) Appender class, does not become resident.
2) Signature: The virus looks for 9090h as the last
   two bytes in a file, virus assumes infected if found & skips file.
3) Replication: Virus looks only for uninfected .COM files in current
   default directory
4) Trigger: None
5) Bomb: None
6) Evasion: None
7) Comments: Very crude structure with much unnecessary PUSHing & POPing.
   several places are noticed where more complex instructions could be
   used more efficiently. All calls are functions of Interrupt 21h. No
   trigger or bomb is present though numerous NOPs and extraneous JMPs
   provide plenty of space for addition.
8) Note: The apparent string "TUQ.RPVS" is simply a sequence of PUSH
   instructions rendered as ASCII.

------------------------------

Date:    04 Aug 90 17:58:51 +0000
From:    [e-mail] (Richard H. Miller)
Subject: Re: other ways for viral injection ?

[e-mail] (Laurent Lathieyre) writes:
>         Alike, did some Trojan horses be discovered in some
>operating systems ? I wonder if operating systems shouldn't
>preferably be delivered in source form rather than in
>compiled form...

A nice thought, but very impratical for the following reasons:

1) Many users of PC level products just want to load their systems and go. To
require them to compile and build their O/S would effectively eleminate their
ability to install the systems themselve. Thus a PC "expert" would come in and
do it. This could also lead to even more problems since this person COULD
insert whatever was desired and the user would probable not know the
difference.

2) The amount of time and effort to build an O/S cna be very long, especially
when one moves into the mini and mainframe arena. It takes almost 24 hours of
wall time to build OS-1100 for Unisys machines. I don't even want to think how
long it would take to compile and build MVS from source.

3) When you release source and the tools to build the O/S, local code WILL
creep into the O/S. Maintenance and upgrades become a royal pain, especially
when no one documents what they did. ["I know I will remember what I did two
years from now and why when we have to upgrade"].

4) O/S source is a trade secret for many vendors. (As one vendor found out
going against IBM)

- --
Richard H. Miller                 Email: [e-mail]
Asst. Dir. for Technical Support  Voice: [phone]
Baylor College of Medicine        US Mail: One Baylor Plaza, 302H
                                           Houston, Texas 77030

------------------------------

Date:    06 Aug 90 07:50:15 +0000
From:    ut-emx![e-mail] (Chris Johnson)
Subject: Gatekeeper Aid 1.0.2 (Mac)

Gatekeeper Aid 1.0.2 has finally been released.  A short descrip-
tion of it and details of where it can be found are included
below.

Gatekeeper Aid is a Startup document (INIT) designed to auto-
matically hunt and kill all known strains of the WDEF virus, as
well as possible future strains and related viruses.  It should
be used to augment the Gatekeeper anti-virus system and may
also be used to augment other anti-virus tools.

Version 1.0.2 of Gatekeeper Aid is designed to correct a number
of problems that surfaced in version 1.0.1.  A complete list of
these problems is included in the documentation.  In addition,
version 1.0.2 improves Gatekeeper Aid's protections and adds
some new features including the ability to retroactively correct
a bug in existing versions of Gatekeeper that is responsible for
about 90% of all the Internal Errors reported.

Users of Gatekeeper Aid are strongly encouraged to upgrade to
this latest version.  Users of anti-virus systems that don't
automatically detect AND REMOVE the WDEF virus are strongly
encouraged to use Gatekeeper Aid to augment their current systems.

Also included with Gatekeeper Aid 1.0.2 is a document which pro-
vides a quick preview of Gatekeeper 2.0.

Gatekeeper Aid 1.0.2 has been posted to comp.binaries.mac and should
appear there relatively soon.  It will also be sent to the info-mac
archives at sumex.stanford.edu and to the simtel archives.  It is
immediately available in the microlib/mac/virus directory on
ix1.cc.utexas.edu and ix2.cc.utexas.edu (take your pick).

- ----Chris (Johnson)
- [e-mail]

DISCLAIMER:  My employer is neither involved with, nor responsible
             for, Gatekeeper and Gatekeeper Aid.

------------------------------

Date:    Tue, 07 Aug 90 01:48:41 -0400
From:    <[e-mail]>
Subject: Joshi Remover (PC)

Here is a program to remove the Joshi virus from hard disks. It can be
assembled by using DEBUG (Like this).

DEBUG
A
MOV     DX,0080
MOV     CX,0001
MOV     BX,0200
MOV     AX,0201
INT     13
CMP     AH,0
JNE     13C
MOV     CX,0008
MOV     AX,0301
INT     13
CMP     AH,0
JNE     150
MOV     CX,0009
MOV     AX,0201
INT     13
CMP     AH,0
JNE     13C
MOV     CX,0001
MOV     AX,0301
INT     13
CMP     AH,0
JNE     150
INT     20
MOV     AH,9
MOV     CX,145
INT     21
INT     20
DB      'Read Error$'
MOV     AH,9
MOV     DX,159
INT     21
INT     20
DB      'Write Error$'

N RMJOSHI.COM
RCX
:80
W
Q

To restore the disk to its origonal condition (like using it on and uninfected
hard disk), use this program.

DEBUG
A
MOV     DX,0080
MOV     CX,0008
MOV     BX,0200
MOV     AX,0201
INT     13
CMP     AH,0
JNE     122
MOV     CX,0001
MOV     AX,0301
INT     13
CMP     AH,0
JNE     136
INT     20
MOV     AH,9
MOV     DX,12B
INT     21
INT     20
DB      'Read Error$'
MOV     AH,9
MOV     DX,13F
INT     21
INT     20
DB      'Write Error$'

N RETURN.COM
RCX
:50
W
Q

This will return the hard disk to it's origonal state (before RMJOSHI was
executed).

Be sure to boot off an unifected diskette before using these programs. Since
Joshi Virus redirects attempts to read or write to the virus, these programs
will not work if the virus is active in memory.

These programs may be used by anybody, as long as they are not modified or
used in another program...<MM>.

------------------------------

Date:    Mon, 06 Aug 90 17:38:05 -0700
From:    [e-mail]
Subject: CVIA Alert (PC)

This is a forward from Aryeh Goretsky of the Computer Virus
Industry Association:
================================================================

Note:  Contact information from the following CVIA Membership Alert
has been removed from the posting, but has been submitted
separately to the Virus-L moderator.

August 6, 1990
CVIA Membership Alert
Originating Members:  [Information Removed]
Alert Type:  Initial Infection Spread
Library Entries:  AirCop; 1253; Leprosy
Entry Types:  Boot Sector; Multipartite; COM Infector

          The second U.S. occurence of the AirCop virus was reported
from Fremont, California on August 3.  The virus had infected a retail
software distributor on multiple machines.  The virus appears
identical to the original AirCop reported by Microsoft.  The virus was
traced back to a software duplicator in Taiwan.

          An unusual virus, called the 1253 virus, has been reported in
Austria and submitted to the CVIA library.  The virus infects COM
files, floppy diskette boot sectors, and hard disk partition tables.
Either of the three forms of the virus are sufficient to transfer an
infection to the other.  In its COM infector form, it increases the
size of infected files by 1253 bytes.  The virus activates on December
24th and corrupts all data on the hard disk and on any inserted
floppies.  An interim detector for the virus is available now to
liaison persons.

          The Leprosy virus has been reported at 11 separate sites in
Northern California within the past five days.  The outbreak appears
to stem from a file uploaded to bulletin boards within the Bay Area
called 486COMP.ZIP, which promises to compare the user's system to a
80486-based PC.  The Leprosy virus is a slow replicator and there is
little chance of contracting this virus ouside of the BBS channels or
from an intentional infection.  A detector is available, however, for
liaison persons if requested.

John McAfee

------------------------------

Date:    Wed, 08 Aug 90 09:28:26 -0700
From:    [e-mail]
Subject: Viruscan Site Licensing

This is a forward from John McAfee:
==================================================================

          Brian Aslakson posted a Virus-L message concerning the cost
of service licenses for VIRUSCAN.  Just so there is no
misunderstanding, I'd like to point out the differences between our
service licenses and our site licenses.  Site licenses, for large
volume organizations, bottom out at $1.90 per machine.  They allow
the use on any machine in the licensed organization.  Service
licenses, on the other hand, are used by organizations that want
to license only a few copies, but want to carry those copies to
other organizations, or sites, and scan any and all machines at the
site.  A service organization may license, say, one copy, but use
the copy on hundreds of machines a day.  As a result, each service
copy of SCAN may generate multiple support calls to our office each
week, as viruses are detected and removal or containment assitance
is requested.  Support costs us time and money, but it is provided
at no charge to our clients.  Accordingly, our service licenses
cost more, per copy, than our site licenses.  Brian suggests that
$5,800 for 100 service copies is unreasonable.  I can't say.  The
folks on our support lines (and not a few of the users of SCAN),
however, seem to feel otherwise.

John McAfee ... ...-....

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 139]
******************************************
VIRUS-L Digest   Friday, 10 Aug 1990    Volume 3 : Issue 140

Today's Topics:

4096 (PC)
postscript trojan
"Re: other ways for viral injection C"
Disk Manager (PC)
Re: 4096 Virus and Checksums (PC)
Re: F-PROT experience (PC)
CVIA Virus Alerts (PC)
Bouncing ball? (PC)
Re: Summary Of Laserwriter Viruses
Re: 4096 Virus and Checksums (PC)
Extremely virulent virus problem (PC)
help!!! (Mac)
Re: Antivirus-viruses
Cost of Protection (Philosophy)
Disk Killer bug (PC)
SCAN, Zenith ZDS (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

---------------------------------------------------------------------------

Date:    08 Aug 90 15:43:04 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: 4096 (PC)

Padgett Peterson <[e-mail]>:

> I have been surprised to the the excitement caused by this virus.
> Admittedly, it uses some "stealth" techniques to hide itself, but
> the "stealth" itself should be detectable in memory.

Yep, the 4096 is easily detectable in memory.   I think the main
cause for worry has been the feeling that there are lots of
people out there who don't use virus scanners, and whose main
hope of noticing an infection is noticing file lengths (or
contents) changing, or programs malfunctioning.   A "stealth"
style virus with few bugs will tend to be less noticeable by
those means than a non-stealthy one.
  I definitely agree, though, that for users who have a good
virus-scanning program, the 4096 is no more worrisome than
a comparable non-stealthy virus would be.

DC

P.S. Detecting a virus in memory is a little more prone to
     false alarms than detecting one in files, because after
     an infected system has been cleaned up the virus
     signature may still make it into memory, because it
     is still in the "cluster gas" somewhere on the disk,
     and may get loaded into unused parts of disk buffers
     or whatever.

------------------------------

Date:    08 Aug 90 20:27:25 +0000
From:    [e-mail] (Terry Reeves)
Subject: postscript trojan

          A few days ago there was a series of messages about a laser
writer trojan horse that set the password to some unknown value.
          A fix was also posted. (a program that could reset the
password without knowing the old one.)
          Noone said what the name of the trojan horse was, or what it
claimed to be good for. Does anyone know?
          The fix included the caveat that it would probably fail on
postscript clones.
          Ok. We have a kyocera Q8010 that has apparently been hit. Or
some bright reader of comp.virus suddenly realised printers have
passwords and just sent down the commands to change it from 0 to
whatever.
          Yes, the fix failed on this clone. I am in contact with
Kyocera, but I am not sure they will be able to help. I fear they will
say you can't reset passwords without knowing the old one.
          It occurs to me that maybe the fix program fails because the
password is in a different spot in the eprom.
          Any ideas? Specifically woud the authors of the fix routines
be interested in adapting them to this printer if I could get them
technical info like the location of the password?
          Anyone agree with me that maybe the password should be in cmos
so we could open the case and yank the battery? Not that agreeing with
me will do much good - but I'd feel better.

Terry Reeves
The Ohio State University
[e-mail]

------------------------------

Date:    Thu, 09 Aug 90 11:55:07 +0700
From:    Jan Christiaan van Winkel <[e-mail]>
Subject: "Re: other ways for viral injection C"

[e-mail] (Laurent Lathieyre) writes:
>I wonder if operating systems shouldn't
>preferably be delivered in source form rather than in
>compiled form...

And even that does not guard you against the virus/trojan Ken Thompson
described in his Turing award lecture.
How can you guarantee that the compiler/assembler or linker does not
insert some extra code, recognizing the fact that it is
compiling/assembling/linking the new version of the compiler, operating
system or whatever?

Therefore I do not agree with mr. Lathieyre: It is better to have one
source of your O/S. I'd rather boot off one of the suppliers disks than
off on I built myself using God knows what utilities...
JC

___  __  ____________________________________________________________________
   |/  \   Jan Christiaan van Winkel      Tel: [phone]  [e-mail]
   |       AT Computing   P.O. Box 1428   6501 BK Nijmegen    The Netherlands
__/ \__/ ____________________________________________________________________

------------------------------

Date:    Thu, 09 Aug 90 15:01:00 +0300
From:    Y. Radai <[e-mail]>
Subject: Disk Manager (PC)

  Michael Greve wrote that his machines have become infected with the
4096 even though the hard disks are protected with Disk Manager.
Several people reacted by saying that Disk Manager is disk partition-
ing software, not anti-viral software.

  Well, I don't think Michael is that far off.  True, Disk Manager is
disk partitioning software.  But it includes an option to make a par-
tition READ-ONLY.  In principle, this should prevent infection of any
file on such a partition.  Of course, since this is only software pro-
tection, it can probably be circumvented.  But I think that it should
be effective against all current file viruses, including the 4096.
So if this option has actually been used on one of the partitions,
files *on that partition* should be protected against the 4096.

  Note that I said that it should be effective against *file* viruses.
I don't recall if it's possible, under Disk Manager, to arrange for
the boot sector to be in the read-only partition.  If it is, then this
should also work against ordinary boot-sector viruses.  However, it
won't work against partition-record viruses, like the Stoned (= Mari-
juana) and EDV.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     (Note new address)

------------------------------

Date:    Thu, 09 Aug 90 15:21:00 +0300
From:    Y. Radai <[e-mail]>
Subject: Re: 4096 Virus and Checksums (PC)

  Steve Albrecht asks about the following statement by Dr. Highland on
the 4096 virus:
>    "This recently published computer virus is particularly
>    disturbing in that...checksum techniques likewise appear to
>    be useless, the virus `disappears' during the checksum
>    process..."
>
>Can someone please elaborate on how the virus avoids the checksum
>process, or perhaps direct me to more detailed information on this
>virus?
>
>In particular, does it avoid all checksum algorithms, or only
>certain ones?  How does it avoid detection from the checksum
>operation?

The virus "disappears during the checksum process" only in the sense
that files infected by this virus do not appear to have been altered
*IF THE VIRUS IS IN MEMORY WHEN CHECKSUMMING IS PERFORMED*.  Didn't
Dr. Highland mention this in his article?  The same is true of some
other viruses, incl. EDV and Number of the Beast (V512).  From this it
is obvious that the answer to your question  whether it avoids *all*
checksum algorithms  is affirmative.  But this is only under the above
circumstances.

  The remedy is obvious: Instead of performing checksumming from your
hard disk, do it only after cold booting from your original (write-
protected) DOS diskette, with the checksum program and database also
on a diskette.  This will ensure that RAM is uninfected when the check-
sum program is run.  (At least it's much surer than depending on checks
such as those advocated by Jim Molini and Chris Ruhl on this forum
several months ago.)

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     (Note new address)

------------------------------

Date:    Thu, 09 Aug 90 15:32:00 +0300
From:    Y. Radai <[e-mail]>
Subject: Re: F-PROT experience (PC)

  Sigurd Andersen asks for opinions on F-PROT.  In my opinion, this
package of 21 utilities includes some excellent programs.  I'll des-
cribe only a few of them:
  F-DRIVER is a small device driver which (1) checks RAM for boot-sec-
tor and partition-record viruses when it is initially activated and
(2) checks each program which is about to be executed to see if it
contains a known file virus.  If so, it stops execution.
  F-LOCK is a RAM-resident program which monitors suspicious activi-
ties.  It is effective not only against known viruses but also against
Trojans and unknown viruses.  In this respect, it resembles FluShot+.
However, it is designed to stop even viruses which write to the disk
by jumping directly to an interrupt handler instead of diverting
interrupt vectors in the normal way.  In practice, this does not work
on all such viruses (e.g. it does not seem to be effective against
the 4096), but since the idea behind the prevention of such viruses
seems to be sound, it's possible that this is just a bug which will
soon be removed.
  F-DISINF scans boot sectors and partition records for known viruses
and optionally removes them.
  F-FCHK scans files for known viruses and new mutations of them and
can cure such files in almost all cases.
  F-SYSCHK scans memory for known viruses.
  F-MMAP displays a map of memory.  It includes memory blocks which
other such utilities do not show (e.g. those near the TOM, where most
boot-sector viruses hide, and I think even those above the 640K mark).

  What I *don't* like in the package are the "self-checking" programs.
I think there are better ways of achieving the same thing.  But, of
course, you don't have to use everything in the package.

  The prices for F-PROT are as follows:

>      Educational institutions:   1-14  computers     $15
>                                  15-500 computers    $1 per computer
>                                  over 500 computers  $500
>
>      Everybody else:             1-7 computers       $15
>                                  8-500 computers     $2 per computer
>                                  over 500 computers  $1000

  F-DRIVER corresponds (approx.) to McAfee's VSHIELD, while F-DISINF
and F-FCHK do the equivalent of McAfee's SCAN and CLEAN (on almost the
same number of viruses).  Prior to Ver. 1.11, F-FCHK was quite slow.
But its speed has since been improved.  It still takes about 50% more
time than SCAN, but it can probably detect more mutations of known vi-
ruses since it uses 2 or 3 identifying strings for almost every virus.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     (Note new address)

------------------------------

Date:    Wed, 08 Aug 90 17:23:07 -0700
From:    [e-mail]
Subject: CVIA Virus Alerts (PC)

This is a forward from Aryeh Goretsky of the Computer Virus
Industry Association:
================================================================

Note:  Contact information from the following CVIA Membership Alert
has been removed from the posting, but has been submitted
separately to the Virus-L moderator.

August 8, 1990
CVIA Membership Alert
Originating Members:  [Information Removed]
Alert Type:  Initial Infection Spread
Library Entries:  Joshi; 4096
Entry Types:  "Stealth"; Boot infectors; File Infectors

          A widespread outbreak of the Joshi virus has been reported in
the Detroit area.  More than two dozen computer stores, small
businesses and individual users have reported infections within the
past three days.  The virus is the "A" variety.  The transmission
vector into the Detroit area has not yet been determined, although
some signs point to a national computer store chain.  Many of the
local retail outlets of this national chain have reported
infections.
          This virus is spreading more rapidly than any previous virus
that has been tracked by this organization.   As a point of
comparison, the Sunday virus (a relatively fast replicator) was in
the public domain (U.S.) for more than eight months before it
reached a point of consistent multiple daily reports.  The Dark
Avenger followed a similar course.  The Joshi virus has been in the
U.S. public domain for less than 45 days, and we are currently
receiving more reports of this virus per day than for the Sunday
and Dark Avenger combined.  We cannot account for this anomaly.
Perhaps it has something to do with being the first known "Stealth"
partition table infector, or perhaps with an opportunistic event
such as the high volume distribution of infected diskettes or
hardware.  In any case and alert is in order.  An interim remover
for the Joshi is available to liaison persons in the event an
infection is detected.

          An August seventh report of the 4096 virus in Vermont marks
the first CVIA reported occurrence of this virus in New England.
 We are continuing to receive multiple daily reports of this virus
from geographic areas previously reported as affected.

John McAfee
408 988 3832

------------------------------

Date:    09 Aug 90 13:17:41 +0000
From:    [e-mail] (mike yacullo)
Subject: Bouncing ball? (PC)

Starting around the beginning of May, our office's IBM/PCs began
showing a strange thing on their screens:  A "bouncing ball" type of
graphic which floats around the screen, bouncing off the boundaries.
The ball appears when I'm in DOS, and disappears when an application
is run.  It's not there all the time, and I don't know what triggers
its appearance.  Anyway, what I'm getting at is:

1) Has anyone else come across this phenomenon?  What is it?

2) Is it a symptom of a deeper problem?  My boss is telling me to
ignore it, but I'm nervous that it might be connected to a virus.

Thanks for your help,
                              Mike
                              [e-mail]

------------------------------

Date:    Wed, 08 Aug 90 16:09:11 -0700
From:    [e-mail]
Subject: Re: Summary Of Laserwriter Viruses

Could someone please mail me a summary of the discussion on
Laserwriter Viruses, specifically: Do they exist and how can they be
detected?

Thanks.

john costello
lewis and clark college
ACS
cos@lclark

------------------------------

Date:    09 Aug 90 20:11:15 +0000
From:    [e-mail] (Johnathan Vail)
Subject: Re: 4096 Virus and Checksums (PC)

[e-mail] (Steve Albrecht) writes:

   In browsing through the April 1990 issue of Computers and Security,
   Volume 9, No. 2, I read the following comments of Dr. Harold
   Highland on the 4096 virus:

          "This recently published computer virus is particularly
          disturbing in that...checksum techniques likewise appear to
          be useless, the virus `disappears' during the checksum
          process..."

   Can someone please elaborate on how the virus avoids the checksum
   process, or perhaps direct me to more detailed information on this
   virus?

Back when it was fun to hack with viral code I thought it would be
necessary to avoid the checksum built into the .EXE header.  The first
approach was to compute a new checksum based on the entire new file.

A better and more efficient way is to simple force the checksum of the
actual added virus code be zero.  That way, any checker will take the
CS of the original file data and add it to the CS of the added virus
code.  This being zero it will result in the same CS as the original.
This method will easily spoof checksums but not CRCs or LRCs.  And I
still don't know how to spoof a combination of these.

I think that there are programs that will wrap around an executable
and detect any changes made to itself.  These can't be beat by the
method described above.  Probably what happens here is the the virus
code gets executed first after being loaded.  It then relocates itself
and hides its tracks.  Then it can pass control back to whatever
program it has infected.  The resulting load image is the same as it
would have been without a virus.

Just some random musings...  jv

[Ed. Unless I'm mistaken, the 4096 doesn't use this sort of mechanism
to hide from checksums; it traps the interrupts that read files and
disinfects files on the fly so that a checksum/crc/whatever actually
sees the non-infected files.]

The inability of snakes to count is actually a refusal, on their part,
    to appreciate the Cardinal Number system. -- "Actual Facts"
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date:    Thu, 09 Aug 90 11:47:54 -0700
From:    Carol anne Clayson <[e-mail]>
Subject: Extremely virulent virus problem (PC)

We're having a problem with an extremely virulent virus.  Aside from
infecting programs, it seems to store itself in parameter ram as well,
so soley reformatting the hard drive doesn't kill it.  It seems to
lock up Windows, Harvard Graphics, and several other graphics based
programs.  We've managed to get it off of our machine, but we're not
sure what floppies have been infected and what ones have not.  We're
looking for a virus checking program that would recognize and remove
this virus.  Does one exist and if so, where can we get it?

Please reply by email ([e-mail]) as I do not
read this newsgroup.

Thank you very much.

C. A. Clayson
- -------

------------------------------

Date:    Thu, 09 Aug 90 21:27:38 -0400
From:    cindy <[e-mail]>
Subject: help!!! (Mac)

I've got something I think could be a virus on my mac pc, but I'm not
sure.  I inserted a floppy and got a wierd flashing dialogue box
flashing and saying "pl ease insert disc" in a different font than it
should, and then the computer loc ked up irrevocably, forcing me to
turn it off.  I have a hard disc, and when I started up again, a game
locked up when I played it.  Same thing...turned off the computer.
And after that, whenever I tried to insert a floppy (having restarted
from the hard disc) I got that same wierd dialogue box, and lock-up.
I have disinfectant 1.7, and gatekeeper that came out in may (I
think), AND vaccine recent edition, and none of those came up with
anything.  ResEdit didn't show anything unusual, either.  So I thought
too many DA's, shut almost all down, no change.  Finally I threw up my
hands, replaced the finder, system, and general files, and it works
(for now).  What the heck?  Is there a new virus out there that would
cause all that?  my disc isn't full!  I'm afraid there's somthing
lurking around on my hard disc I can't see.  can anyone help?  Please
e-mail cindy (cxb135 at psuvm.psu.edu)

------------------------------

Date:    09 Aug 90 16:43:10 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Antivirus-viruses

In addition to the viruses described in the original posting, some of
the variants of Yankee Doodle are anti-virus viruses - they modify the
Ping-Pong virus, so it will self-destruct.

- -frisk

- --
Fridrik Skulason      University of Iceland  |
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: [e-mail]    Fax: [phone]  |

------------------------------

Date:    9 August, 1990
From:    Padgett Peterson <[e-mail]>
Subject: Cost of Protection (Philosophy)

          I am astounded by the assertation that $5800 for 100 service
copies of McAfee's SCAN is considered excessive. Considering the
continuing effort, response time, and updates required, the cost seems
minimal compared that of sending technicians out unarmed (yes, we have
a service license). Just the savings in time alone in battling
infections and the knowlege of what you are facing justifies the cost.

          More important, at a time when many manufacturers require
individual copies for each CPU, the concept of the service and site
license, both available from McAfee and very few others, are godsends
to overworked staffs.  Besides which, I can think of very few packages
available for $58 each, much less ones that can be used on any
machine. No-one thinks twice about the telephone company charging more
for a business line than for a residential one.  Similarly, the $25
"shareware" fee for home use cannot be equated to the unlimited use
"service license" fee. If an alternative is desired, nothing is
stopping anyone from writing their own software. For me, the price is
cheap and the concept well worth supporting.

                                                  Padgett Peterson
                                              Personal Opinions

------------------------------

Date:    09 Aug 90 14:54:08 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: Disk Killer bug (PC)

The Disk Killer virus has a bug (at least one) that causes it to
sometime/often/usually mark the wrong sectors as bad in the FAT when
it infects a diskette.  If the diskette is later written to, this
often results in the virus's on-disk code being overlayed, rendering
the diskette non-bootable and non-infectious (although the boot sector
is still there, so scanners will still see it as infected).  Does
anyone know in any detail under what circumstances the bug shows up?
From some limited testing, it looks as though the wrong sectors are
marked bad if a freshly- formatted diskette is used in a machine with
the virus in memory, but the right sectors are marked bad if the
diskette already has considerable stuff on it when it becomes
infected.  Does this sound right to others who have looked at it?

DC

------------------------------

Date:    10 August, 1990
From:    Padgett Peterson <[e-mail]>
Subject: SCAN, Zenith ZDS (PC)

          After my last posting, Mr. McAfee called to tell me that it is
not necessary to boot from a write-protected floppy for SCAN to detect
a virus resident in memory & dangerous ones are checked for each time
SCAN runs (to check for all memory resident viruses, the /m option
should be used). Since some machines require special drivers for fixed
disk access that would not be on the floppy, this is good to know.

          During our installation of Enigma-Logic's Virus-Safe on PCs we
experienced problems on a limited but significant number of Zenith 158
& 159 (PC & XT) machines: Each time one booted up, a changed boot
sector was reported. Use of DEBUG revealed that something in the OS
was periodically placing a time stamp in the boot record (logical
sector 0) and Virus-Safe was properly flagging the change. Hard drives
formatted with the signatures ZDS3.1 and ZDS3.2 (Z-DOS ver 3.1 & 3.2)
were the most prevalent.

          A call to Zenith revealed that they had had some reports of
that type and would have to get back with me about exactly what was
going on. They also stated that while some anti-virus routines had
reported difficulty, others did not. When I have more information, it
will be passed on. In the meantime, if you have a Zenith that reports
constant changes to the boot sector, this may be the problem (then
again, maybe you have a boot sector infector).

------------------------------

End of VIRUS-L Digest [Volume 3 Issue 140]
******************************************